The explicit FILE IT gate is a strong pattern because it makes authorization visible. I would also bind the approved issue fields to a snapshot and give the executor a short-lived token, so a later page update cannot silently change the destination. What other write action would you keep behind an explicit human phrase?
Thank you, that is a sharp suggestion, and we already do most of the snapshot part. When BugIt shows the preview, it fingerprints the operation, the provider, the destination, the account and the full content, plus the channels (Slack, Teams and so on) the write will be announced to. The account part is a one way id of the saved credential. At write time BugIt recomputes the fingerprint and refuses if anything changed, so a new destination, a swapped token or an edited body sends you back to a fresh preview. Each approval is used once, and a preview expires after an hour.
The short lived executor token is a good idea we don't do today. BugIt uses your own credential, kept in the OS credential store (for Jira Cloud and Azure DevOps, the sign in of Atlassian's and Microsoft's own MCP servers), and holds no token of its own.
To your question: every write already sits behind the phrase. That covers a new ticket, a comment, an edit, an attachment, and removing a comment or attachment. Edits are limited to summary, description, labels and priority. We kept workflow changes like transitions, assignment and issue links out of scope entirely rather than gating them. When BugIt runs in Claude Code, a guard also denies the assistant calling the tracker's own MCP write tools directly, so those writes stay on the gated path.
indiainfranotes
The explicit FILE IT gate is a strong pattern because it makes authorization visible. I would also bind the approved issue fields to a snapshot and give the executor a short-lived token, so a later page update cannot silently change the destination. What other write action would you keep behind an explicit human phrase?