Outward-facing and hard-to-undo actions ask first in the conversation, and act once on a yes #7882

When the forge's agent tries an outward-facing or hard-to-undo action, it is now asked in the conversation and done only after the person says yes. A yes does it exactly once.

What changed

• One list: ASKING in src/crew/conversation_confirm.ts names the tools that ask first: release and rollback, archive and delete, subscriptions, budgets, grants and limits, secrets, app variables, proposal tokens, invites, claim links, SSH keys, and every admin-scope tool. Some tools have an action that only reads, such as list; that action does not ask. A test fails if an admin-scope tool is missing from the list, or if a name on it is not a tool.
• The agent's call: askedFirst in src/http/mcp/shared.ts runs before the fence's hold and the scope check. The call does nothing and answers needs_confirm with a confirm id and does, one sentence of what it will do. A confirm turn is written to the person's conversation. Values of secret-looking arguments (token, secret, key, value, password) are shown as (hidden) in that sentence.
• Admin tools: an admin's agent, holding the usual rw token, can reach admin-scope tools only through such a confirm. For a person who is not an admin those tools still read as "no tool named …".
• The yes: POST /api/v1/conversation-confirms/:id, in src/http/api/conversation_confirms.ts, with its OpenAPI contract.

- Only the person's own browser session on the same origin can say yes. A bearer token gets 401, a cross-origin request 403, and another person's session 404. - answerHeld in src/core/fence.ts marks the confirm answered and clears its stored arguments in the same transaction that reads them. A second yes is 409 answered; a yes 10 minutes on or later is 410 expired. A migration adds the answered_at column, with its pin. - The call runs with the arguments that were stored, recorded on the trail as the person via the agent. It uses admin scope only if the person is an admin. - It writes a tool turn that names the undo where there is one: archive back, repo_settings back, close with state: "open", take_back after a merge, and so on. - The hold cap now counts only confirms not yet answered.

• tools/list: for an admin holding a token without admin scope, the first page's _meta.hidden (and the initialize instructions) lists the hidden admin tools in one sentence. It says how to reach them: an admin-scope token, or a confirm in the conversation. scripts/mcp-tools.ts now writes (admin scope) on those rows of docs/MCP.md, so the marks follow the code. docs/MCP.md has a new section, "Asked first in the conversation".

What to look at

• A tool's run cannot see that it came from a yes rather than a direct call. The yes is protected by its session-only, same-origin route and the once-only claim.
• A confirm that is never answered keeps its stored arguments, a secret's value included, in conversation_held. Nothing sweeps those rows yet.
• There is no conversation page in the UI yet, so the yes is reachable only through the API route. That page belongs to the conversation UI work under #7640.

What was run

• test/conversation-confirm.test.ts (9 tests) covers: the list against every admin-scope tool; the sentence hiding a secret; needs_confirm with its confirm turn; a yes that runs once and names the undo; a second yes; a late yes; bearer, cross-origin and other-person refusals; repo_settings reached through a confirm; a non-admin's agent finding no such tool; and tools/list for an rw admin token showing the sentence and no repo_settings.
• Also green: bun scripts/gate.ts, bun x tsc --noEmit, and the fence, via-token, conversations, contract and openapi-coverage suites. The MCP suites passed too: mcp-size, mcp-tools, mcp-docs, mcp-sessions, mcp-secrets, mcp-hooks and others.
• scripts/fast.ts could not narrow the tests because scripts/mcp-tools.ts changed, so I picked those suites myself.

How to try it: as an admin, mint a conversation token. Have it call archive with { repo, archived: true, dryRun: false }. Then, from the same browser session, POST the returned confirm id to /api/v1/conversation-confirms/:id.

🤖 Generated with Claude Code

Closes #7650

When the forge's agent tries an outward-facing or hard-to-undo action, it is now asked in the conversation and done only after the person says yes. A yes does it exactly once.

What changed

• One list: ASKING in src/crew/conversation_confirm.ts names the tools that ask first: release and rollback, archive and delete, subscriptions, budgets, grants and limits, secrets, app variables, proposal tokens, invites, claim links, SSH keys, and every admin-scope tool. Some tools have an action that only reads, such as list; that action does not ask. A test fails if an admin-scope tool is missing from the list, or if a name on it is not a tool.
• The agent's call: askedFirst in src/http/mcp/shared.ts runs before the fence's hold and the scope check. The call does nothing and answers needs_confirm with a confirm id and does, one sentence of what it will do. A confirm turn is written to the person's conversation. Values of secret-looking arguments (token, secret, key, value, password) are shown as (hidden) in that sentence.
• Admin tools: an admin's agent, holding the usual rw token, can reach admin-scope tools only through such a confirm. For a person who is not an admin those tools still read as "no tool named …".
• The yes: POST /api/v1/conversation-confirms/:id, in src/http/api/conversation_confirms.ts, with its OpenAPI contract.

- Only the person's own browser session on the same origin can say yes. A bearer token gets 401, a cross-origin request 403, and another person's session 404. - answerHeld in src/core/fence.ts marks the confirm answered and clears its stored arguments in the same transaction that reads them. A second yes is 409 answered; a yes 10 minutes on or later is 410 expired. A migration adds the answered_at column, with its pin. - The call runs with the arguments that were stored, recorded on the trail as the person via the agent. It uses admin scope only if the person is an admin. - It writes a tool turn that names the undo where there is one: archive back, repo_settings back, close with state: "open", take_back after a merge, and so on. - The hold cap now counts only confirms not yet answered.

• tools/list: for an admin holding a token without admin scope, the first page's _meta.hidden (and the initialize instructions) lists the hidden admin tools in one sentence. It says how to reach them: an admin-scope token, or a confirm in the conversation. scripts/mcp-tools.ts now writes (admin scope) on those rows of docs/MCP.md, so the marks follow the code. docs/MCP.md has a new section, "Asked first in the conversation".

What to look at

• A tool's run cannot see that it came from a yes rather than a direct call. The yes is protected by its session-only, same-origin route and the once-only claim.
• A confirm that is never answered keeps its stored arguments, a secret's value included, in conversation_held. Nothing sweeps those rows yet.
• There is no conversation page in the UI yet, so the yes is reachable only through the API route. That page belongs to the conversation UI work under #7640.

What was run

• test/conversation-confirm.test.ts (9 tests) covers: the list against every admin-scope tool; the sentence hiding a secret; needs_confirm with its confirm turn; a yes that runs once and names the undo; a second yes; a late yes; bearer, cross-origin and other-person refusals; repo_settings reached through a confirm; a non-admin's agent finding no such tool; and tools/list for an rw admin token showing the sentence and no repo_settings.
• Also green: bun scripts/gate.ts, bun x tsc --noEmit, and the fence, via-token, conversations, contract and openapi-coverage suites. The MCP suites passed too: mcp-size, mcp-tools, mcp-docs, mcp-sessions, mcp-secrets, mcp-hooks and others.
• scripts/fast.ts could not narrow the tests because scripts/mcp-tools.ts changed, so I picked those suites myself.

How to try it: as an admin, mint a conversation token. Have it call archive with { repo, archived: true, dryRun: false }. Then, from the same browser session, POST the returned confirm id to /api/v1/conversation-confirms/:id.

🤖 Generated with Claude Code

When the forge's agent tries an outward-facing or hard-to-undo action, it is now asked in the conversation and done only after the person says yes. A yes does it exactly once.

What changed

• One list: ASKING in src/crew/conversation_confirm.ts names the tools that ask first: release and rollback, archive and delete, subscriptions, budgets, grants and limits, secrets, app variables, proposal tokens, invites, claim links, SSH keys, and every admin-scope tool. Some tools have an action that only reads, such as list; that action does not ask. A test fails if an admin-scope tool is missing from the list, or if a name on it is not a tool.
• The agent's call: askedFirst in src/http/mcp/shared.ts runs before the fence's hold and the scope check. The call does nothing and answers needs_confirm with a confirm id and does, one sentence of what it will do. A confirm turn is written to the person's conversation. Values of secret-looking arguments (token, secret, key, value, password) are shown as (hidden) in that sentence.
• Admin tools: an admin's agent, holding the usual rw token, can reach admin-scope tools only through such a confirm. For a person who is not an admin those tools still read as "no tool named …".
• The yes: POST /api/v1/conversation-confirms/:id, in src/http/api/conversation_confirms.ts, with its OpenAPI contract.

- Only the person's own browser session on the same origin can say yes. A bearer token gets 401, a cross-origin request 403, and another person's session 404. - answerHeld in src/core/fence.ts marks the confirm answered and clears its stored arguments in the same transaction that reads them. A second yes is 409 answered; a yes 10 minutes on or later is 410 expired. A migration adds the answered_at column, with its pin. - The call runs with the arguments that were stored, recorded on the trail as the person via the agent. It uses admin scope only if the person is an admin. - It writes a tool turn that names the undo where there is one: archive back, repo_settings back, close with state: "open", take_back after a merge, and so on. - The hold cap now counts only confirms not yet answered.

• tools/list: for an admin holding a token without admin scope, the first page's _meta.hidden (and the initialize instructions) lists the hidden admin tools in one sentence. It says how to reach them: an admin-scope token, or a confirm in the conversation. scripts/mcp-tools.ts now writes (admin scope) on those rows of docs/MCP.md, so the marks follow the code. docs/MCP.md has a new section, "Asked first in the conversation".
• Merge with main: the conflict was in the generated tool table in docs/MCP.md. I took main's table, regenerated it with the (admin scope) marks, and put back the new docs section. main dropped FLOW ONLY from repo_settings, so its confirm sentence now says "description or visibility".

What to look at

• A tool's run cannot see that it came from a yes rather than a direct call. The yes is protected by its session-only, same-origin route and the once-only claim.
• A confirm that is never answered keeps its stored arguments, a secret's value included, in conversation_held. Nothing sweeps those rows yet.
• There is no conversation page in the UI yet, so the yes is reachable only through the API route. That page belongs to the conversation UI work under #7640.

What was run

• test/conversation-confirm.test.ts (9 tests) covers: the list against every admin-scope tool; the sentence hiding a secret; needs_confirm with its confirm turn; a yes that runs once and names the undo; a second yes; a late yes; bearer, cross-origin and other-person refusals; repo_settings reached through a confirm; a non-admin's agent finding no such tool; and tools/list for an rw admin token showing the sentence and no repo_settings.
• After the merge, these are green: bun scripts/gate.ts, bun x tsc --noEmit, and the conversation-confirm, conversation-fence, mcp-size, mcp-tools, mcp-docs, via-token, openapi-coverage and contract suites (240 tests).
• Before the merge, these also passed: the conversations suite and the other MCP suites (mcp-sessions, mcp-secrets, mcp-hooks and others).
• scripts/fast.ts could not narrow the tests because scripts/mcp-tools.ts changed, so I picked those suites myself.

How to try it: as an admin, mint a conversation token. Have it call archive with { repo, archived: true, dryRun: false }. Then, from the same browser session, POST the returned confirm id to /api/v1/conversation-confirms/:id.

🤖 Generated with Claude Code

When the forge's agent tries an outward-facing or hard-to-undo action, it is now asked in the conversation and done only after the person says yes. A yes does it exactly once.

What changed

• One list: ASKING in src/crew/conversation_confirm.ts names the tools that ask first: release and rollback, archive and delete, subscriptions, budgets, grants and limits, secrets, app variables, proposal tokens, invites, claim links, SSH keys, and every admin-scope tool. Some tools have an action that only reads, such as list; that action does not ask. A test fails if an admin-scope tool is missing from the list, or if a name on it is not a tool.
• The agent's call: askedFirst in src/http/mcp/shared.ts runs before the fence's hold and the scope check. The call does nothing and answers needs_confirm with a confirm id and does, one sentence of what it will do. A confirm turn is written to the person's conversation. Values of secret-looking arguments (token, secret, key, value, password) are shown as (hidden) in that sentence.
• Admin tools: an admin's agent, holding the usual rw token, can reach admin-scope tools only through such a confirm. For a person who is not an admin those tools still read as "no tool named …".
• The yes: POST /api/v1/conversation-confirms/:id, in src/http/api/conversation_confirms.ts, with its OpenAPI contract.

- Only the person's own browser session on the same origin can say yes. A bearer token gets 401, a cross-origin request 403, and another person's session 404. - answerHeld in src/core/fence.ts marks the confirm answered and clears its stored arguments in the same transaction that reads them. A second yes is 409 answered; a yes 10 minutes on or later is 410 expired. A migration adds the answered_at column, with its pin. - The call runs with the arguments that were stored, recorded on the trail as the person via the agent. It uses admin scope only if the person is an admin. - It writes a tool turn that names the undo where there is one: archive back, repo_settings back, close with state: "open", take_back after a merge, and so on. - The hold cap now counts only confirms not yet answered.

• tools/list: for an admin holding a token without admin scope, the first page's _meta.hidden (and the initialize instructions) lists the hidden admin tools in one sentence. It says how to reach them: an admin-scope token, or a confirm in the conversation. scripts/mcp-tools.ts now writes (admin scope) on those rows of docs/MCP.md, so the marks follow the code. docs/MCP.md has a new section, "Asked first in the conversation".
• Merge with main: the conflict was in the generated tool table in docs/MCP.md. I took main's table, regenerated it with the (admin scope) marks, and put back the new docs section. main dropped FLOW ONLY from repo_settings, so its confirm sentence now says "description or visibility".
• Check fix: the forge's check failed one test, "the index is current", because the routes index I edited by hand did not match the generator's output. I regenerated it with bun scripts/openapi-routes.ts; only that one line moved.

What to look at

• A tool's run cannot see that it came from a yes rather than a direct call. The yes is protected by its session-only, same-origin route and the once-only claim.
• A confirm that is never answered keeps its stored arguments, a secret's value included, in conversation_held. Nothing sweeps those rows yet.
• There is no conversation page in the UI yet, so the yes is reachable only through the API route. That page belongs to the conversation UI work under #7640.

What was run

• test/conversation-confirm.test.ts (9 tests) covers: the list against every admin-scope tool; the sentence hiding a secret; needs_confirm with its confirm turn; a yes that runs once and names the undo; a second yes; a late yes; bearer, cross-origin and other-person refusals; repo_settings reached through a confirm; a non-admin's agent finding no such tool; and tools/list for an rw admin token showing the sentence and no repo_settings.
• After the index fix, these are green: bun x tsc --noEmit, test/openapi-routes.test.ts (the test that failed), and the openapi-coverage, contract and conversation-confirm suites.
• After the merge, these also passed: bun scripts/gate.ts, and the conversation-fence, mcp-size, mcp-tools, mcp-docs and via-token suites. The conversations suite and the other MCP suites passed before the merge. None of these files changed with the index fix.
• scripts/fast.ts could not narrow the tests because scripts/mcp-tools.ts changed, so I picked those suites myself.

How to try it: as an admin, mint a conversation token. Have it call archive with { repo, archived: true, dryRun: false }. Then, from the same browser session, POST the returned confirm id to /api/v1/conversation-confirms/:id.

🤖 Generated with Claude Code

Parked by the crew: the check stayed red through 2 automatic tries

When the forge's agent tries an outward-facing or hard-to-undo action, it is now asked in the conversation and done only after the person says yes. A yes does it exactly once.

What changed

• One list: ASKING in src/crew/conversation_confirm.ts names the tools that ask first: release and rollback, archive and delete, subscriptions, budgets, grants and limits, secrets, app variables, proposal tokens, invites, claim links, SSH keys, and every admin-scope tool. Some tools have an action that only reads, such as list; that action does not ask. A test fails if an admin-scope tool is missing from the list, or if a name on it is not a tool.
• The agent's call: askedFirst in src/http/mcp/shared.ts runs before the fence's hold and the scope check. The call does nothing and answers needs_confirm with a confirm id and does, one sentence of what it will do. A confirm turn is written to the person's conversation. Values of secret-looking arguments (token, secret, key, value, password) are shown as (hidden) in that sentence.
• Admin tools: an admin's agent, holding the usual rw token, can reach admin-scope tools only through such a confirm. For a person who is not an admin those tools still read as "no tool named …".
• The yes: POST /api/v1/conversation-confirms/:id, in src/http/api/conversation_confirms.ts, with its OpenAPI contract.

- Only the person's own browser session on the same origin can say yes. A bearer token gets 401, a cross-origin request 403, and another person's session 404. - answerHeld in src/core/fence.ts marks the confirm answered and clears its stored arguments in the same transaction that reads them. A second yes is 409 answered; a yes 10 minutes on or later is 410 expired. A migration adds the answered_at column, with its pin. - The call runs with the arguments that were stored, recorded on the trail as the person via the agent. It uses admin scope only if the person is an admin. - It writes a tool turn that names the undo where there is one: archive back, repo_settings back, close with state: "open", take_back after a merge, and so on. - The hold cap now counts only confirms not yet answered.

• tools/list: for an admin holding a token without admin scope, the first page's _meta.hidden (and the initialize instructions) lists the hidden admin tools in one sentence. It says how to reach them: an admin-scope token, or a confirm in the conversation. scripts/mcp-tools.ts now writes (admin scope) on those rows of docs/MCP.md, so the marks follow the code. docs/MCP.md has a new section, "Asked first in the conversation".
• This round, merging main again: the conflict was in the hooks and repo_settings rows of the generated tool table in docs/MCP.md. I kept main's new wording for both rows and regenerated the table, so both now carry the (admin scope) mark from this pull. The "Asked first in the conversation" section is kept. The OpenAPI routes index was already up to date.

What to look at

• A tool's run cannot see that it came from a yes rather than a direct call. The yes is protected by its session-only, same-origin route and the once-only claim.
• A confirm that is never answered keeps its stored arguments, a secret's value included, in conversation_held. Nothing sweeps those rows yet.
• There is no conversation page in the UI yet, so the yes is reachable only through the API route. That page belongs to the conversation UI work under #7640.

What was run

• test/conversation-confirm.test.ts (9 tests) covers: the list against every admin-scope tool; the sentence hiding a secret; needs_confirm with its confirm turn; a yes that runs once and names the undo; a second yes; a late yes; bearer, cross-origin and other-person refusals; repo_settings reached through a confirm; a non-admin's agent finding no such tool; and tools/list for an rw admin token showing the sentence and no repo_settings.
• After this merge, these are green: bun scripts/gate.ts, bun x tsc --noEmit, and the conversation-confirm, conversation-fence, mcp-size, mcp-tools, mcp-docs, via-token, openapi-routes, openapi-coverage and contract suites (533 tests).
• Earlier in this pull the conversations suite and the other MCP suites (mcp-sessions, mcp-secrets, mcp-hooks and others) also passed. I did not run them again after this merge.
• scripts/fast.ts could not narrow the tests because scripts/mcp-tools.ts changed, so I picked those suites myself.

How to try it: as an admin, mint a conversation token. Have it call archive with { repo, archived: true, dryRun: false }. Then, from the same browser session, POST the returned confirm id to /api/v1/conversation-confirms/:id.

🤖 Generated with Claude Code

This merges main into torque/7650-outward-facing-and-hard-to-undo-actions. Git merged it without conflicts, including in docs/MCP.md, so nothing needed resolving by hand. After a fetch, the branch on the forge is level with the merge commit.

From main, docs/MCP.md now has #7700's line that events filters by kind (a settings change is on the trail with who changed it and from what to what). From this branch, it keeps the admin-scope marks on outward-facing and hard-to-undo tools and the conversation-confirm route. No code was changed to get here.

Checks:

• Gate and type check: bun scripts/gate.ts and bun x tsc --noEmit both pass.
• Tests: scripts/fast.ts exited 2 because scripts/mcp-tools.ts is in the diff, so it couldn't name the tests and I chose them by hand. They cover the MCP docs, tools and size, the settings trail from main, and this branch's conversation-confirm, MCP, OpenAPI, migration and fence code. That is 604 tests in 34 files, all passing.

🤖 Generated with Claude Code

Parked by the crew: the check stayed red through 2 automatic tries

Before an agent does something outward-facing or hard to undo, it now asks in the conversation first. The person's yes performs the stored call once, and only once.

What it does

• One list. src/crew/conversation_confirm.ts names the actions that ask first: release and rollback, archive and delete, subscriptions and budgets, secrets, tokens, ssh keys, and every needsAdminScope tool.
• The ask. When a via token calls one of these, src/http/mcp.ts answers needs_confirm with a confirm id and one sentence saying what will happen. It also stores a confirm turn in the conversation.
• The yes. POST /api/v1/conversation-confirms/:id must be a same-origin request from the person's own session, never the agent's token. The confirm is tied to that person and to the exact arguments. It runs once: a second yes, or a yes after 10 minutes, is refused.
• Admin tools. An admin can reach admin-scope tools this way, deliberately. Where the action has an undo (take_back, revert, reopen), the result turn names it.
• Hidden tools. tools/list for an admin holding a non-admin token says in one sentence that admin tools are hidden and how to reach them: an admin-scope token, or a confirm in the conversation. docs/MCP.md marks those rows (admin scope).

This push only merges main, which went in cleanly. The last red check on this branch was "shard 34 killed after 39 s, running test/wave-pulls.test.ts". That run came between restarts on a runner at 17% free disk. The same file passes here in 1.4 s, so the failure came from the runner, not from this change. No code or test was changed to get it green.

Checks run here: bun scripts/gate.ts and bun x tsc --noEmit pass (after bun install picked up main's new happy-dom). scripts/fast.ts called the diff too broad to name tests (exit 2, because scripts/mcp-tools.ts changed), so I ran these 17 files myself: conversation-confirm, conversation-fence, conversations, mcp-docs, mcp-size, mcp-size-rank, mcp-tools, brief-mcp-size, openapi-coverage, openapi-routes, openapi, openapi-served, token-admin-scope, wave-pulls, schema-migrations, brief-foreign-fence and pin-refusal. 591 pass, 0 fail.

To try it: in a conversation on the preview, ask the agent to archive a repository. A confirm card appears, and the archive happens only when you press yes.

Where to look: src/crew/conversation_confirm.ts for the list and the single-use binding, src/http/api/conversation_confirms.ts for the yes endpoint, and test/conversation-confirm.test.ts.

🤖 Generated with Claude Code

When the forge's agent tries an outward-facing or hard-to-undo action, it now asks first in the person's conversation. The person can say yes from a page or the terminal, a yes does the stored call once, and stored arguments and one-time secrets no longer stay at rest. This addresses @sentinel's review in order.

What changed

1. proposal_tokens asks on its verb. The predicate in src/crew/conversation_confirm.ts now names the argument it reads, so not("verb", "list") applies to proposal_tokens. Mint and revoke ask; list does not. I checked every other tool on the list: secrets, app_env and ssh_keys really do use action.
2. Old confirms are swept. sweepHeld in src/core/fence.ts marks every unanswered confirm older than 10 minutes as answered and clears its arguments. hold, waitingFor and answerHeld each run it first, so a secret, token or key is not kept past 10 minutes. A partial index on waiting rows keeps the sweep cheap; the migration is not on main yet, so its pin is regenerated.
3. Old confirms no longer count toward the cap. Swept rows are no longer waiting, so they never count toward HELD_MAX (50 per conversation).
4. One-time results are not kept. mint_invite, claim_link and proposal_tokens have a new once sentence. The person gets the link or credential in the answer, and the conversation's tool turn keeps only that sentence.
5. A person can reach the yes. The yes logic now lives in one function, sayYes in src/actions/conversation_confirms.ts, with three ways in:

- Web: Settings → Confirms (/settings/confirms, src/web/pages/confirms.ts) lists each waiting sentence with a Yes button. It is a same-origin form from the person's own session; a bearer token gets 403. A one-time result is shown on the answer page itself, never in a flash cookie. - Terminal: the palette's Confirms (src/tui/screens/confirms.ts) lists the same; y opens a dialog with the sentence, and Yes does it. - API: the existing route now calls sayYes too.

The needs_confirm message to the agent now names both places, so the agent can point the person there.

1. The sentence is safe to trust, and the note is computed once. Argument text has control, format (including bidi) and line-break characters replaced before it goes into the sentence. hiddenAdminNote is computed once in initialize.

One test changed: a second yes on an expired confirm now answers 410 expired, not 409 answered. My earlier test expected 409, but the call was never done, so "expired" is the honest answer.

New tests, in test/conversation-confirm.test.ts:

• mint and revoke ask, list does not, both in the predicate and over MCP;
• the sweep clears arguments and frees the cap;
• the invite link reaches the person but not the conversation;
• the sentence stays on one line;
• the Settings page lists and says yes, and refuses cross-origin and bearer requests;
• the terminal flow y → Yes does the action.

tsc --noEmit, scripts/gate.ts, scripts/design-lint.ts and scripts/mcp-tools.ts --check pass. fast.ts said the diff was too broad to name tests (exit 2), so I picked them: the confirm, fence, MCP, OpenAPI, route-coverage, security, terminal and settings-nav suites all pass. The rest of the suite is left to the forge's check.

Not done: Confirms has no live badge in the feed; you reach it from Settings or the terminal palette. A full conversation page that shows confirms inline is not on main; it belongs to the rest of #7640.

To try it on the preview: have an agent with a via token call archive on one of your repositories. Open Settings → Confirms, press Yes, and the repository is archived. A second Yes on the same confirm does nothing.

🤖 Generated with Claude Code

Agent-proposed actions that are outward-facing or hard to undo now wait for a person's yes. The person can say yes from the API, from Settings → Confirms (/settings/confirms) or from the terminal's Confirms screen. All three call one action, sayYes in src/actions/conversation_confirms.ts, which runs the stored call once.

• What asks: proposal_tokens asks before mint and revoke but not before list. It now decides by reading verb instead of action.
• Stale confirms: a confirm left unanswered for more than 10 minutes is marked stale and its arguments are cleared. Stale confirms don't count toward the limit on waiting confirms, and no secret stays stored. A partial index limits that sweep to confirms still waiting.
• One-time results: invite links, claim links and tokens from mint_invite, claim_link and proposal_tokens are shown to the person once on the answer. They are not put in a flash cookie or the conversation, which keeps only a sentence.
• The yes from Settings: it is a form posted from the person's own browser session, never a token, and cross-origin posts are refused.
• Sentences: confirmSentence strips control, format and line-break characters from argument text.

This push fixes the check failures caused by adding the page and palette entry:

• /settings/confirms now reports session and render in Server-Timing, like /settings/password.
• docs/design/audit.md has an entry for the page.
• test/palette-roster.test.ts lists the new Confirms entry for signed-in people. That test pins the palette's exact list, so updating it was the expected change, not a bug fix.

waves in the terminal > nothing to cut, an unparsable wave, and a non-admin are refused with nothing written also failed in the check. It passed in three runs here, and this change doesn't touch the waves screen or any key it uses; the Confirms screen is only reachable from the palette. It looks like a flake under load, so the code is unchanged for it.

To try it: sign in, open Settings → Confirms (or Confirms (y) from the terminal palette), have the forge's agent ask to mint a proposal token, and press Yes. The token appears once on that page and is gone on reload.

The gate, tsc --noEmit and bun scripts/design-lint.ts all pass. The changed test files pass: server-timing-sweep, design-audit, palette-roster, conversation-confirm and tui-waves.

🤖 Generated with Claude Code