You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
fix(server): Claude Plan no longer asks again for a tool approved for the session - #36340
Interim status while watching the pull request; no code changed in this pass. The brief listed no items to change. Pull request 36340 is open at 06ecc14, mergeable, with no reviews, no line comments and no issue comments at the time of reading. Its checks (Test Server 1-8, Lint, Build and Typecheck, Test, and the Macroscope checks) were queued or in progress, none failed. watch_pull_request is on for the pull request; the final result follows once checks pass and no high-rated bot finding is open.
Commit 9efd960 (origin/main). Ran T3CODE_DEV_SEED=0 vp run dev in a fresh worktree and drove the web UI with headless Playwright, since the preview browser was blocked on this host. Created a project and a Replay (dev) thread with 5 turns as the thread to read. Plan is no longer a composer toggle after #33131, so in a Full access Claude Haiku 5.5 thread I asked Claude to call create_threads with interactionMode "plan", runtimeMode "full-access", and a prompt to make 4 sequential t3_thread_read calls (view activity, afterPosition -1, then nextPosition, limit 2). The child opened with permissionMode plan. In the child thread I answered each Command approval card with More -> "Always allow this session". Observed: 4 approval cards for mcp__t3-code__t3_thread_read (afterPosition -1, 1, 3, 5). The dev database's runtime-request projection has 4 command requests on one provider turn, all resolved acceptForSession, 3 of them created after the first was resolved. Also added a failing adapter test (branch factory/repro-23918): in a Full access Plan turn, the second canUseTool call for mcp__t3-code__t3_thread_read after acceptForSession raises a new approval request.
Evidence
Run the web app with a fresh synthetic five-turn history. In Claude Haiku 5.5, Full access + Plan, request four sequential t3_thread_read calls using activity, limit 2, and positions -1, 1, 3, 5. Choose More → Always allow this session whenever asked. Environment: Chromium, light theme, 1440×1000.
Hook-, rule-, and safety-originated approval requests and grant lifetime across session restart were not exercised; this proof covers the reported repeated-read flow.
Tests
None in this pass. Read the pull request, its reviews, comments and the head commit's check runs over the REST API: no failures, checks still running.
Not in this change
The grant is keyed by tool name only and lasts for the adapter session; it is not keyed by sub-agent (agentID) and survives leaving and re-entering Plan, the same lifetime as the CLI's own session rule.
Session approvals whose CLI suggestions are not a whole-tool rule (for example a Bash prefix rule or a directory rule) are not remembered by the adapter; if Plan re-asks for those too, that is a separate change.
t3_thread_read has Tool.Readonly false in mcp/toolkits/orchestrator/tools.ts; marking it read-only would stop Plan asking for it at all, which changes a tool annotation rather than fixing session grants.
The SDK omits decisionReasonType from its CanUseTool types although it passes it at runtime; the adapter reads it with an in check, and the older comment in claudeApprovalPresentation saying the SDK drops decision_reason_type is now out of date.
Who did the work
Written by Claude Fable 5.2, in Claude Code
Reviewed by GPT-6.1 Sol, in Codex, and by Claude Opus 5.5, each on its own
Proof captured by GPT-6.1 Sol and checked by Claude Opus 5.5
…#23918)
Failing repro: after Always allow this session on mcp__t3-code__t3_thread_read
in a Full access Plan turn, the next call raises another approval request.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
… the session
In Plan the Claude CLI records the session rule T3 Code sends back for
"Always allow this session", but its Plan check still asks for every tool
without a read-only annotation, so each t3_thread_read call raised a new
approval card.
The adapter now remembers a whole-tool session grant and answers the mode's
own ask from it. An ask from a hook, an ask rule or a safety check carries a
different reason and still reaches the user.
Fixes#23918
Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>
Macroscope's review found this PR approvable — Claude now remembers explicit whole-tool session approvals instead of repeatedly prompting for mode-based requests. The change preserves separate ask-rule and safety-check handling and does not change default permissions.
You can add or adjust custom eligibility rules. Learn more.
No actionable comments were generated in the recent review.
Walkthrough
The Claude adapter now records eligible Plan-mode session grants and reuses them for qualifying mode-triggered requests. A regression test checks that a granted tool does not prompt again for a mode request, while a hook-triggered request still prompts.
Changes: Plan-mode session grants
Layer / File(s)
Summary
Record and reuse Plan-mode grants apps/server/src/orchestration-v2/Adapters/ClaudeAdapterV2.ts, apps/server/src/orchestration-v2/Adapters/ClaudeAdapterV2.test.ts
The adapter records an allowed tool when the approval result contains an eligible session-level allow rule. It skips a later approval request only when the request is mode-triggered, no ask rule matched, standing grants are not suppressed, and the tool has a recorded grant. The test checks that hook-triggered requests still prompt.
This change stops repeated approval cards in Claude Plan mode for tools already approved for the session. Hook-triggered and other asks still require approval. No remaining merge-blocking risk was identified, and adapter tests cover both the reuse case and the hook case.
Pre-merge checks: 3 · 1
Failed checks: 1 warning
Check name
Status
Explanation
Resolution
Description check
The description is an interim status note rather than a completed PR description in the repository template. It has substantive content: a reproduction on main, a before/after proof with linked artifa…
Rewrite the description to follow the repository template headings: Problem, Change, Scope, Verification. Under Problem, state the bug in one or two sentences: after 'Always allow this session', Plan mode re-prompts for the same MCP tool, a…
Passed checks: 3 passed
Check name
Status
Explanation
Title check
The title names the fix and its user-visible effect: Claude Plan mode no longer re-asks for a tool approved for the session. This matches the main change in ClaudeAdapterV2.ts, which records session-w…
Linked Issues check
[#23918] The issue requires that a session approval of mcp__t3-code__t3_thread_read stop later approval requests in Claude Plan mode with Full access. At head, ClaudeAdapterV2.ts adds planSessionToolG…
Out of Scope Changes check
All changed code lies in ClaudeAdapterV2.ts and its test file. The adapter diff adds only the grant Ref, the grant-check guard, and the grant-recording logic on the approval result path, all tied to r…
Full details: Title check
Explanation
The title names the fix and its user-visible effect: Claude Plan mode no longer re-asks for a tool approved for the session. This matches the main change in ClaudeAdapterV2.ts, which records session-wide whole-tool grants and uses them for Plan-mode asks. It follows the conventional commit style of the template.
Full details: Linked Issues check
Explanation
[#23918] The issue requires that a session approval of mcp__t3-code__t3_thread_read stop later approval requests in Claude Plan mode with Full access. At head, ClaudeAdapterV2.ts adds planSessionToolGrants (a per-session Ref set). The permission callback records a tool name when an approval result is allow and its updatedPermissions contain an addRules allow rule for that toolName with no ruleContent. A later canUseTool call is auto-allowed only when decisionReasonType is 'mode', matchedAskRule is undefined, suppressAlwaysAllowRule is not true, and the tool is in the grant set. Hook, ask-rule, and safety asks keep the approval flow. The check follows the existing never-policy and dangerous-removal denies. The diff confirms this logic. The repro test (two 'mode' calls plus one 'hook' call) and the adapter test suite (409 passed) are reported as passing. The reported CLI probe supports the reason-type premise. The full UI flow was not re-run, so the fix is supported by code and adapter tests rather than an end-to-end run. Prefix and directory rules and subagent keying are out of this PR's stated scope, and the issue does not require them as coding acceptance criteria. The issue's 'additional authorization explained' expectation is non-coding and not assessed.
Full details: Out of Scope Changes check
Explanation
All changed code lies in ClaudeAdapterV2.ts and its test file. The adapter diff adds only the grant Ref, the grant-check guard, and the grant-recording logic on the approval result path, all tied to repeated approval cards for session-approved tools. The test change keeps the repro test, adds decisionReasonType to the helper (a supporting test change), and adds a hook-ask case that checks the guard does not bypass hook asks. No unrelated refactoring, tool annotation change (t3_thread_read Readonly stays false), or documentation change appears in the reviewed diff. The PR description states the grant is not keyed by agentID and does not cover prefix or directory rules. These are stated limits, not unrelated changes.
Full details: Description check
Explanation
The description is an interim status note rather than a completed PR description in the repository template. It has substantive content: a reproduction on main, a before/after proof with linked artifacts, a stated scope (whole-tool session grants keyed by tool name, not prefix or directory rules), and a list of exclusions. It links the issue (#23918) and names the tests run. Several template sections are missing or weak. The Problem section has no clear one-to-two-sentence statement of the expected behavior. The Change section does not describe the adapter logic in template form. The Scope section does not say whether the change is a bug fix. It links the issue, which satisfies that part. The Verification section includes focused tests and manual checks, but the 'Tests' section says 'None in this pass', which conflicts with the Verification reported elsewhere in the description. The description also says 'Interim status while watching the pull request' and gives a 'watch_pull_request' note, which is process text that does not belong in the PR body. The author also reports that checks were still running and that the final result would follow, so the status is not final. The attribution section is present, as the template asks for an agent's model and harness. The description is mostly complete in substance, but it is not cleanly structured to the template and has contradictory test reporting.
Resolution
Rewrite the description to follow the repository template headings: Problem, Change, Scope, Verification. Under Problem, state the bug in one or two sentences: after 'Always allow this session', Plan mode re-prompts for the same MCP tool, and give the expected behavior. Under Change, summarize the adapter change in ClaudeAdapterV2.ts: whole-tool session grants recorded from approvals and used only for mode-triggered asks. Under Scope, keep the issue link (#23918) and state that this is a bug fix. Under Verification, list the exact focused test commands and their results (for example, the Plan-filtered run with 6 passing and the full file run with 409 passing), and state what was not checked (hook, rule, and safety approval paths, and grant lifetime across session restart). Remove the interim status text and the 'Tests: None in this pass' line, since they conflict with the reported validation. Keep the attribution line with the model and harness. Re-check the description after CI finishes and state the final check results.
Finishing Touches
Generate unit tests (beta)
Commit to this branch
Create a new PR
Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
Limit details: You’ve used all 10 included reviews currently available.
This branch has not been deployed
No deployments
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
size:M30-99 changed lines (additions + deletions).vouch:trustedAuthor is trusted by repo permissions or the VOUCHED list.
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
github-actions
Bot
added
vouch:trusted
![macroscopeapp[bot]](https://avatars.githubusercontent.com/in/900172?s=60&v=4){kind=small}
Interim status while watching the pull request; no code changed in this pass. The brief listed no items to change. Pull request 36340 is open at 06ecc14, mergeable, with no reviews, no line comments and no issue comments at the time of reading. Its checks (Test Server 1-8, Lint, Build and Typecheck, Test, and the Macroscope checks) were queued or in progress, none failed. watch_pull_request is on for the pull request; the final result follows once checks pass and no high-rated bot finding is open.
Fixes #23918
Reproduction on main
Commit 9efd960 (origin/main). Ran
T3CODE_DEV_SEED=0 vp run devin a fresh worktree and drove the web UI with headless Playwright, since the preview browser was blocked on this host. Created a project and a Replay (dev) thread with 5 turns as the thread to read. Plan is no longer a composer toggle after #33131, so in a Full access Claude Haiku 5.5 thread I asked Claude to call create_threads with interactionMode "plan", runtimeMode "full-access", and a prompt to make 4 sequential t3_thread_read calls (view activity, afterPosition -1, then nextPosition, limit 2). The child opened with permissionMode plan. In the child thread I answered each Command approval card with More -> "Always allow this session". Observed: 4 approval cards for mcp__t3-code__t3_thread_read (afterPosition -1, 1, 3, 5). The dev database's runtime-request projection has 4 command requests on one provider turn, all resolved acceptForSession, 3 of them created after the first was resolved. Also added a failing adapter test (branch factory/repro-23918): in a Full access Plan turn, the second canUseTool call for mcp__t3-code__t3_thread_read after acceptForSession raises a new approval request.Evidence
Run the web app with a fresh synthetic five-turn history. In Claude Haiku 5.5, Full access + Plan, request four sequential t3_thread_read calls using activity, limit 2, and positions -1, 1, 3, 5. Choose More → Always allow this session whenever asked. Environment: Chromium, light theme, 1440×1000.
The base recording is split before the fourth approval following an automation click failure. Both runs completed all four reads in one provider turn. Seed and launch script, browser driver, sanitized runtime summary.
Not shown:
Tests
None in this pass. Read the pull request, its reviews, comments and the head commit's check runs over the REST API: no failures, checks still running.
Not in this change
incheck, and the older comment in claudeApprovalPresentation saying the SDK drops decision_reason_type is now out of date.Who did the work
Run by the t3code factory in T3 Code.