[MarcoDotIO]

Problem

Clicking Always allow this session on an ACP approval stops the turn when the agent offers no allow_always option. The agent asked for permission, the user approved, and T3 answered cancelled.

The default approval card offers that choice for every ACP agent that doesn't supply its own options, which today means the ACP Registry and FX flavors. The path is:

1. The agent sends session/request_permission with, for example, [allow_once, reject_once].
2. beginApprovalRequest emits the approval with no options, because the flavor has no approvalOptions. Web (DEFAULT_APPROVAL_OPTIONS in ComposerPendingApprovalActions.tsx) and mobile (PendingApprovalCard.tsx) then show their default buttons, including Always allow this session.
3. selectPermissionOptionId(params, "acceptForSession") looks only for allow_always, finds nothing, and the handler responds { outcome: { outcome: "cancelled" } }.

This is a regression. #6502 reported this symptom on Grok ("Grok stops working. When I asked why, it told me that it had been canceled"), and #8358 fixed it in the old Grok adapter by falling back to allow_once. The V2 rewrite in #2829 didn't carry that fallback into the shared ACP adapter. Grok and Antigravity no longer hit it because their flavors hide choices the agent doesn't offer, but the default flavors still do.

Change

selectPermissionOptionId now answers acceptForSession with allow_always when the agent offers it, and otherwise with allow_once. That is never a wider grant than the user chose, and it approves the call they were looking at.

accept still never escalates to allow_always, and decline is unchanged.

Scope and approval

This is a small fix for an obvious bug: one function and one test. It restores the behavior already accepted in #6502 and #8358 for all default ACP flavors. The request and response shapes and the buttons are unchanged, so there is no visible UI change.

Verification

Added a table test to apps/server/src/orchestration-v2/Adapters/AcpAdapterV2.test.ts. It runs a real adapter session against acp-mock-agent.ts, sends a permission request and responds with acceptForSession.

Before the fix, on upstream/main:

× answers Always allow with allow-once when the agent offers no allow-always option
AssertionError: expected { outcome: 'cancelled' } to deeply equal { outcome: 'selected', …(1) }
Tests  1 failed | 1 passed | 87 skipped (89)

After the fix:

Tests  2 passed | 87 skipped (89)

The second table case passes both before and after. It guards that allow_always is still preferred when offered.

Also ran:

• vp test run on AcpAdapterV2.test.ts and GrokAdapterV2.test.ts: 99 passed
• vp lint and vp fmt --check on packages/provider-acp/src/server and apps/server/src/orchestration-v2/Adapters
• tsc --noEmit in packages/provider-acp and apps/server

Not checked:

• A real third-party ACP agent or a running client. The test uses the mock agent, so what happens after cancelled comes from the [Bug]: Always allow in this session stops Grok 4.6 #6502 report, not from a new reproduction.
• The label's promise for later calls. An agent with no allow_always will ask again on its next tool call, because T3 doesn't remember the approval for agent prompts. clientPolicyGrants still records the session grant for T3's own client-side terminal requests, as it already did.

Claude Opus 5.5 (Claude Code desktop app)

🤖 Generated with Claude Code

[macroscopeapp]

Approvability

Verdict: Approved at 151a688

Macroscope's review found this PR approvable — The ACP adapter now falls back to allow-once instead of cancelling when a user selects session approval and the agent offers no allow-always option. This honors the explicit approval without widening the agent’s permission grant or changing default approval policies.

^{You can add or adjust custom eligibility rules. Learn more.}

[coderabbitai]

No actionable comments were generated in the recent review.

Recent review info

Run configuration

• Source mode: Auto
• Repository: pingdotgg/t3code
• Branch: main
• File: .coderabbit.config.ts
• Commit: c8a601c
• Layers: Repository TS config
• Review profile: CHILL
• Plan: Advanced
• Run ID: ea06f02b-d892-420c-ba37-538a6c11a532

Commits

Reviewing files that changed from the base of the PR and between c8a601c and 151a688.

Files selected for processing: 2

• apps/server/src/orchestration-v2/Adapters/AcpAdapterV2.test.ts
• packages/provider-acp/src/server/adapter.ts

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 7 remain after this review.

Walkthrough

For ACP acceptForSession decisions, the adapter now selects allow_once when allow_always is unavailable. Tests cover both cases.

Changes: ACP permission selection

Layer / File(s)	Summary
Session acceptance option selection packages/provider-acp/src/server/adapter.ts, apps/server/src/orchestration-v2/Adapters/AcpAdapterV2.test.ts	The adapter prefers allow_always and falls back to allow_once for acceptForSession. Tests verify the selected option when each option set is offered.

Estimated code review effort: 2 (Simple) | ~10 minutes

Change: Bug fix

Suggested reviewers: juliusmarminge

Merge Risk: Minimal · up to 151a6

Session approval falls back to one-time approval when needed. No merge-blocking issue is evident.

Pre-merge checks: 4

Check name	Status	Explanation
Title check		The title clearly and concisely describes the ACP permission fix: falling back from Always allow to allow-once prevents the turn from being cancelled.
Description check		The description includes all required sections. It explains the problem, change, scope justification, focused tests, observed results, and untested scenarios.
Linked Issues check		Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check		Check skipped because no linked issues were found for this pull request.

Finishing Touches

Generate unit tests (beta)

• Create a new PR

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

[maria-rcks]

Note

Written by gpt-6.1-sol on behalf of Maria

Verified in a real dev environment

verified as-is at 151a6881bd69b47cc7877061000051bb21692a91. no code changes.

ran separate github/main (30b9c4a956a6c595fda5c8b2c439a6aaebc861b0) and pr dev environments, one server at a time. used repository playwright with google chrome on linux. created the project, provider, and threads through the web ui with fresh isolated state, without mocks or fixtures.

used real codex gpt-6.1-sol through codex-acp 0.16.0 (legacy zed bridge), configured as a local acp provider, in read-only mode with t3 supervised permissions. this real bridge offers only allow_once and reject_once for file edits, reaching the exact regression. a transparent stdio logger captured the permission messages without changing them.

sent the same patch command for approval-proof.txt on both revisions and clicked more > always allow this session:

main: options = [allow_once, reject_once]
      response = { outcome: { outcome: "cancelled" } }
      turn aborted; approval-proof.txt absent on disk

pr:   options = [allow_once, reject_once]
      response = { outcome: { outcome: "selected", optionId: "approved" } }
      turn completed; approval-proof.txt contains "approval granted"

main approval before the click:

pr result after the same click:

neighboring behavior also passed through the same running client and provider:

• the next file edit prompted again, preserving the provider's one-time grant.
• approve returned selected/approved and created allow-once-proof.txt.
• decline returned selected/abort and left deny-proof.txt absent.
• a real command offering allow_always still selected approved-execpolicy-amendment and printed session command approved.

ran the existing acp and grok adapter suites through blacksmith: 99 passed. head ci has 23 successful and 7 skipped checks, with none failing or pending.

short runtime transcript

Not verified

native ios/android, electron, macos/windows, other real acp agents, and remote/tunnel connections were not exercised on this linux vm. the current codex acp bridge offers allow_always for file edits, so the legacy real bridge above was used to reach the missing-option case.