Sign up
View stargazers13Sign up

Repeated t3_thread_read approvals after session approval in Claude Plan mode with Full access#23918

opened11h agobyLluquibu

What happened

While using Claude in T3 Code Desktop with Full access selected and Plan enabled, reading another thread repeatedly displayed Command approval cards for mcp__t3-code__t3_thread_read.

Requests occurred while paging through messages, activity, and truncated item text. Session approval did not prevent later requests in the observed turn.

Diagnosis

Source inspected at v0.1.2, commit 044f07257c9684ae4543bd1e1ebf9c394e9e3830:

These facts identify the permission path but do not establish why Claude requested approval again. SDK decision reasons, effective permission rules, process continuity, and subagent attribution were not captured.

Steps to reproduce

Suggested minimal reproduction, not yet executed in isolation:

  1. Create two test threads with enough dummy text to require pagination.
  2. In the source thread, select Claude, Full access, and Plan before starting a turn.
  3. Ask Claude to read the other thread, continuing through pages and truncated items.
  4. On a t3_thread_read approval card, select Always allow this session.
  5. Observe subsequent calls using afterPosition or itemId/textOffset.

Expected: an authorized history-reading workflow can continue within the stated permission scope, with any additional authorization explained.

Observed in the real session: repeated approval requests, including requests created after session approval.

Version

Affected Desktop version reported: 0.1.2. The local server also reports 0.1.2. Triage CLI version only: 0.1.2-nightly.20261022.3541.

Environment

Windows x64, build 10.0.26200. T3 Code Desktop Beta, Claude Agent provider, affected run model claude-opus-5-5. Effective Claude CLI and Agent SDK versions were not established.

Evidence

shell
1Read-only SQLite inspection found, for one affected run:
2
3tool: mcp__t3-code__t3_thread_read
4distinct approval requests: 19
5request kind: command
6recorded decisions:
7 accept: 9
8 acceptForSession: 10
9requests created after the first acceptForSession resolved: 17
10distinct recorded providerThreadId values: 1
11distinct recorded providerTurnId values: 1
12
13These identifiers do not establish that all calls used the same Claude process. The original report counted 17 requests in a narrower history window.

Related issues

No exact duplicate found in the searches performed. https://github.com/pingdotgg/t3code/issues/4974 concerns Auto mode outside Plan. https://github.com/pingdotgg/t3code/issues/3744 concerns side effects executing before plan approval.

Fix applied or workaround

No fix applied. Session approval was used in the incident and is not a verified workaround. No correction for this exact symptom was confirmed in the upstream sources reviewed.

No permissions, service state, source code, or database contents were changed during triage.

Filed by

Codex, GPT-6, via t3 triage.

MMarvinFS7h ago
Synced from GitHub

Same here on Windows 11, T3 Code 0.1.3-nightly.20261023.3553, Claude Code 2.1.309, Full access + Plan. Since the 2026-10-20 nightly, every MCP call and every shell command Claude Code can't classify as read-only shows an approval card. Read and plain ls/grep still run.

As far as I can tell this comes from #17963: in Plan, the adapter now always installs the permission callback, and Claude Code's plan mode sends it anything not auto-approved, not only writes. Allow rules in ~/.claude/settings.json work around it for shell commands, but not for MCP tools: in plan mode Claude Code sends any MCP tool without a read-only annotation to the callback even when an allow rule matches, so those cards can't be silenced from the user side.

Can you please retract that change and reconsider the mechanics - in the current implementation it became absolutely unusable for automated runs.