feat(mcp): let MCP sessions approve and reject issues after the user confirms

Part of BYT-9292 user journey 1 (the second of three PRs in plans/2026-10-13-mcp-decision-matrix.md). The first, #21588, is merged.

Today an agent can prepare a change or file an access request, but every approval waits for someone to open the console: ApproveIssue and RejectIssue are refused to MCP in every mode. A refusal does not stop a user who wants their agent to approve, because they can hand it a browser with their own session. So the guard becomes asking the user. The question is asked by the client, not by the model in chat, so an instruction planted in something the agent reads cannot approve anything.

What changes:

• A new tool, decide_issue(issue, decision, comment?), approves or rejects a database-change issue or an access request. First it asks the user through MCP elicitation, the MCP specification's way for a server to ask the user something. The form shows the issue's name and title, what it changes, the current approval step, the requester and the comment the decision records, with one checkbox. For an access request, what it changes is the targets, schema and container, the query, whether results are unmasked or exportable, and when the grant expires. For a new database, it is the instance and, when set, the cluster, owner, table, character set and collation. The tool acts only when the user ticks the box and accepts. Declining, cancelling or leaving the box unticked changes nothing.
• The form fits Claude Code's dialog. Read from the Claude Code 2.1.300 binary and confirmed live on 2.1.302: its dialog shows four lines of a form's message, or the first three and "… (+N more lines)", and cuts each line six columns short of the terminal width. So each line does one job, with its bounded part first: the decision and the issue; the targets, counted before they are named; the statement or query; then the approval step, the requester and the comment. An access request's terms (unmasked, export, expiry) open the last line. Its schema and container stay on the targets line: the requester can set them to any length, so only a fixed label comes before the query. They follow a single database's name, so on an 80-column terminal a long name can cut them, and the dialog's "…" shows the cut. With several databases they come after the count and before the names. A form for one change or for an access request fits in four lines. A plan with several changes shows its first change, numbered with the total ("Change 1 of 3"), then Claude Code's "… (+N more lines)", so what the first change does (its statement, its release or its new database's settings) is always within the first three lines. A long list of targets or a long comment is cut at the end of its own line, not the statement: on an 80-column terminal the statement line shows at least 55 characters of SQL.
• An answer counts only for a form this server sent, about the issue as it still is. The form goes out with a request state: a digest of what the user is asked about, signed with a key derived from the server secret, together with the workspace, user, client, decision and issue. An answer without a state that verifies is treated as no answer, and the user is asked. The digest includes the update times of the issue, the plan and the access grant. So an accepted answer decides nothing, and the agent is told to call again, when anything changed while the form was open: the plan edited (including a setting the form does not show, such as prior backup), a step decided by someone else, the issue rejected and requested again, or the title changed. Today's clients never see the state: the go-sdk carries it between the two rounds of one call. A client on the 2026-07-28 protocol echoes it back.
• The decision applies only to the issue the user confirmed. The tool sends the issue's update time with the decision. The review workflow compares it with the issue under the issue's row lock, and refuses the decision if it no longer matches. So a step decided between the tool's check and the approval is refused, not decided again at the next step.
• Issue text cannot add lines to the form. Every value taken from the issue or the agent is quoted with %q, which escapes line breaks. A cut says what it leaves out: "(partial)" before a statement or query that the form cuts at 300 characters, with its full size after it; "3 of N changes shown"; and "statements not shown" for a release. Without "(partial)", the message carries the whole statement, though a client may still cut the line. The form carries no link, because the MCP specification asks servers not to put clickable URLs in a form. The tool's result carries the issue link.
• A client that cannot show the form gets a refusal with the issue's console link.
• After the user confirms, the normal approval workflow decides as it does for a person: the approval rule's role, the project's self-approval setting and the last-editor rule. The approval comment records that the decision was confirmed in the MCP client. A refusal comes back in the server's own words, with the issue link.
• A requester can decide their own access request. A requester may lack bb.accessGrants.get (project developers do), so the tool reads the user's own request through SearchMyAccessGrants, as the console's issue page does.
• ApproveIssue and RejectIssue move from FORBIDDEN to WRITE, but only decide_issue can use them. The tool attaches the confirmed decision (procedure, issue and the issue's update time) to the context of its internal request. The gate serves the call only when the procedure and issue match. call_api cannot set a context value, so it is refused and pointed to decide_issue.
• Role requests stay in the console. Approving one grants a project role, which MCP does not do yet. decide_issue serves database changes and access requests only. Any other type is refused with the console link, and the refusal is written to the audit log out of band, as a refused connection is.
• RetryIssueApproval and ActivateAccessGrant stay FORBIDDEN. The approval-decision reason now reads "it can let a change or an access request pass its approval without an approver deciding it".

Copy: the "Never, in any mode" line drops "approve issues". A new Read-write row, "Approve or reject issues", says each decision is confirmed in the user's MCP client, role requests are decided in the console, and the approval rules and self-approval setting apply as in the console. The propose and request-access rows no longer say an agent never approves. The change tool's guidance points to decide_issue, and the query tool's guidance no longer says a person approves an access grant. The comments behind the issueless-rollout guard no longer argue from approval being FORBIDDEN to MCP. The guard stays, because without a linked issue no approval check runs at all.

Not in this change

• ApproveIssue and RejectIssue now appear in search_api. A call_api call on either is refused and names decide_issue.
• A failed or malformed elicitation surfaces as an SDK error that names the input request, not as a tool message. Nothing changes. The database-choice elicitation in tool_resolve.go has the same go-sdk limit.
• In a Read-only workspace, the user is asked first, and the ceiling then refuses the approval with its own remedy. A pre-check would duplicate the gate's rule.
• The form is checked against Claude Code only. Its dialog draws the message as plain text, so Markdown and HTML show as written. No second client here can show a form: Cline 4.1.21 declares no elicitation, so its users get the console link. A client that renders the message as Markdown could style issue text inside the form, because %q escapes line breaks, not markup. No escaping works for every renderer and still keeps SQL readable.
• The form does not show a change's prior-backup setting or a new database's environment. The plan's update time is in the digest, so changing any of them makes an open form's answer stale.
• An approver who neither filed an access request nor holds bb.accessGrants.get gets no form, because the tool cannot read the grant. The console shows that approver the issue without the grant.
• A request state has no expiry. An answer acts only while the issue is at the version the form was sent for, and every review action moves that version.

Size

+2490/−185 lines in 36 files: 866 production lines (tool_decide.go is 743), 1,479 test lines, and the rest copy, proto comments and generated code. The classification change, the tool and the call_api refusal have to ship together, so the PR is not split further. The review fixes (1114c34f88, d437f8fc86, 16b6c98c98, a80de2b578, and 1a26f6c287, which reverses the layout b8e462b3c5 tried) add 695 lines, 496 of them tests.

Tests and verification

• tool_decide_test.go:
  • Accepting approves, with one form whose message is exactly four lines, the attached confirmation carrying the issue's update time, and the comment. The reject path works the same way.
  • Declining, cancelling, an accepted but unticked box, a malformed answer (the SDK's schema error) and an elicitation error all change nothing.
  • A client with no form support, or only URL elicitation, gets the link. An answer sent unasked by a client that cannot confirm is refused.
  • An answer that a form-capable client sends unasked, with no request state or a forged one, is not acted on: the user is asked.
  • If the plan's statement is replaced, the plan is edited where the form does not show it, a step is decided by another approver, the issue is rejected and requested again, or the title changes while the form is open, nothing is decided, and the result says to call again. A decline is still reported as a decline, so the agent does not ask again.
  • A 2026-07-28 client: the first call returns the form and the state. An answer without the state is asked again. The state with a different comment is refused as stale. The state with the same comment decides.
  • The state verifies only for the same workspace, user, client, decision, issue and digest.
  • Issue text cannot add a line: a create-database name with a line break stays inside its quotes, and a statement's line breaks stay visible. Cuts are stated: "(partial)" before a cut statement or query, and each change of a five-change plan carries its number and the total. A failed read of the plan, a statement or the access grant sends no form.
  • The workflow's refusal and the Read-only ceiling's refusal come back in the server's words, with no cause added by the tool.
  • The access-grant summary is pinned line by line. A grant's schema and container come after one database's name and before a list of names, and a long schema, container or database name never reaches the query line; a cut query is marked partial, and the title is quoted.
  • A user's own access request is read without GetAccessGrant, and a search that finds nothing sends no form. A new database's cluster, owner, table, character set and collation are shown.
  • Role requests are refused, both asked as usual and with an answer sent unasked, and so are unknown types. Each refusal writes one audit row.
  • What Claude Code shows is checked at 80 and 120 columns (TestDecideIssueFormShowsTheChangeInClaudeCodesDialog) with a model of its dialog: four lines, or three and "… (+N more lines)"; each line cut six columns short of the width; wide characters take two columns. The cases are one long target, many targets, a long statement, several changes, an access request with a long query, an access request on one long database, with a long schema and with a long container, and wide characters. In each, the visible lines start with the decision, the targets with their count, the start of the statement (marked when cut), and the approval line or how much is left out. On 2026-10-20 the real dialog in Claude Code 2.1.302 matched the model line for line at 80 and 120 columns, on a 12-target change with a cut statement and on a three-change plan with a Chinese title: 16 of 16 lines, including where wide characters are cut.
• Review workflow: TestReviewIssueAppliesAConfirmedActionOnlyToTheConfirmedVersion approves on the confirmed version, and refuses with the new reason when the issue is edited between the workflow's read and its lock. In backend/api/v1, TestMapReviewErrorSaysWhenAConfirmedIssueChanged pins the refusal's words, and TestConfirmedUpdateTimeComesFromTheMCPConfirmation pins where the version comes from.
• Gate:
  • TestMCPGateServesAnIssueDecisionOnlyWithItsConfirmation refuses a call with no confirmation, the wrong issue, the other decision, or a Read-only ceiling. Its confirmations carry an update time, as the tool's do.
  • TestCallAPICarriesNoConfirmation shows that call_api attaches nothing.
  • TestConfirmationReachesTheConnectInterceptors sends a marked request through the in-memory transport into a real Connect handler.
  • The FORBIDDEN membership pin and the classification inventory are updated: READ 68, WRITE 39, EXCLUDED 78, FORBIDDEN 34.
• Live: TestMCPGrantIssuesAndAccessRequests (backend/tests, renamed from TestMCPGateRefusesGrantIssues) shows call_api refused. It then shows the requester's confirmed self-approval refused by the workflow with self-approval off, and the same approval succeeding with it on, with the grant going ACTIVE. That approval passes the update-time check, so the time survives protojson and Postgres exactly. TestMCPDeveloperApprovesTheirOwnAccessRequest has a project developer, who cannot get access grants, file a request and approve it under an approval rule that names developers, with self-approval on. The grant goes ACTIVE. The test fails without the change.
• Mutations, each failing a test: removing the provenance check, accepting on decline, skipping the elicitation, reading the answer before the capability check, a type check that always serves, reading the answer before the type check, acting on an answer without a verified state, ignoring a changed digest, leaving the comment out of the digest, leaving the identity or the decision out of the signature, printing the create-database name raw, ignoring a failed statement read, dropping the cut note, not writing the refusal's audit row, checking for a change before a decline, leaving the issue's or the plan's update time out of the digest, sending no version with the decision, the workflow ignoring the version or checking it on its unlocked read, the gate comparing the whole confirmation, the refusal's words ignoring the reason, not showing the schema, the old first line, change lines without the count, always reading the grant with GetAccessGrant, accepting an empty search, leaving out a new database's cluster, owner, table or collation, the statement back on the targets line, the count after the names, the schema and container after several names or before the query, no "(partial)" on a statement or a query, the grant's terms on a line of their own, and the comment on a line of its own.
• Local gates: buf format, buf lint and buf generate, gofmt, go vet, golangci-lint (no findings on the lines this PR changes), the server build, pnpm --dir frontend fix and pnpm --dir frontend test (565 files, 6,228 tests, on the copy commit; the frontend has not changed since), comment share 15% at open (22% over 19 lines in the first review fixes, 18% over 13 lines in a80de2b578; b8e462b3c5 and 1a26f6c287 together add 6 comment lines and no code), and the full Go suite as CI runs it after each review fix, last at a80de2b578: 120 packages ok each time, none failed. At 1114c34f88 the 11 packages the fixes reach ran fresh, among them backend/tests, backend/api/v1, backend/api/mcp and backend/component/review; at 16b6c98c98, backend/tests, backend/api/v1, backend/api/mcp, backend/server and backend/bin/server/cmd ran fresh; at a80de2b578, all 120. The rest came from Go's test cache, their inputs unchanged since the last fresh run. b8e462b3c5 and 1a26f6c287 change one rendering function that only backend/api/mcp uses, so that package ran fresh at each. After main was merged in (fix(api)!: refuse an access grant where just-in-time access is off #21587 now refuses an access grant where just-in-time access is off, so c53249a176 turns it on in one more test), the full suite ran fresh at c53249a176: 121 packages ok, none failed.

Release note

MCP sessions in Read-write mode can approve and reject database changes and access requests with the new decide_issue tool, after the user confirms each decision in their MCP client. Clients that cannot show the confirmation form get a link to the issue instead. The project's approval rules and self-approval setting apply as in the console, and role requests are still decided in the console.

Receipts

🤖 Generated with Claude Code