Sign up
View stargazersSign up

[Bug] Claude: Full access threads ask for approval on every tool call since nightly 20261020#22483

opened20d agobyFfeledori

What happened

since today's update, every Claude thread on my local T3 Code asks for approval on every tool call. the thread is set to Full access. threads on my remote T3 server (Linux VM) still work fine.

Diagnosis

T3 Code does not send set_permission_mode to the Claude session anymore. Because of this, the Claude CLI stays in default mode and asks for approval on each tool call.

  • Up to nightly 0.1.1-nightly.20261019.3373, T3 sent query.set_permission_mode with mode: "bypassPermissions" after each Claude session start. The last one in my logs is at 2026-10-19T23:14:20Z.
  • On nightly 20261020.3386, .3399, .3401 and .3411, T3 sends this message 0 times.
  • The query.open options did not change. They still contain permissionMode: "bypassPermissions" and allowDangerouslySkipPermissions: true.
  • On each session start, the CLI init event reports permissionMode: "default". Before, the follow-up set_permission_mode changed the mode to bypass. Now nothing changes it.
  • A change of the mode in the composer does not help. T3 restarts the session with the same options and again sends no set_permission_mode.

The Claude CLI version is not the cause. The remote server uses the same CLI (2.1.304) and does not have the problem.

Steps to reproduce

  1. Install T3 Code nightly 0.1.1-nightly.20261020.3411 on macOS.
  2. Start a new Claude thread in Full access mode.
  3. Ask the agent to run one shell command.
  4. See the approval popup for the command.
  5. In the provider log for the thread, see the system/init event with permissionMode: "default", and no query.set_permission_mode event.

Version

0.1.1-nightly.20261020.3411 (last good: 0.1.1-nightly.20261019.3373)

Environment

macOS 27.0.1 arm64, Node 24.22.0, claude 2.1.304

Evidence

shell
1# query.set_permission_mode events in logs/provider/*, per day
2 5 2026-10-14 "mode":"bypassPermissions"
3 17 2026-10-15 "mode":"bypassPermissions"
4 26 2026-10-16 "mode":"bypassPermissions"
5 3 2026-10-17 "mode":"bypassPermissions"
6 12 2026-10-18 "mode":"bypassPermissions"
7 29 2026-10-19 "mode":"bypassPermissions"
8 0 2026-10-20
9
10# one thread today, after a switch from Supervised back to Full access
112026-10-20T19:59:52.436Z query.close
122026-10-20T19:59:53.325Z query.open permissionMode=bypassPermissions allowDangerouslySkipPermissions=true
132026-10-20T19:59:53.382Z system/init permissionMode=default
14# no query.set_permission_mode follows; every tool call then shows an approval popup

#22147 has the same symptom, but a different cause. There, a thread starts in Auto mode without --allow-dangerously-skip-permissions, so a later switch to Full access fails. Here, the thread starts in Full access with that flag. It fails because the set_permission_mode message is gone since the 20261020 nightlies.

Fix applied or workaround

None applied. A change back to nightly 20261019.3373 will probably fix it (not tested).

Filed by

claude (opus-5.5) via T3 Code

JJulius Marminge20d ago

Note

Grok responding on behalf of Julius.

Thanks for the log counts, they line up with the code. This is a regression from #21806, which merged just before the first nightly you saw it on.

The only place the Claude adapter sends set_permission_mode is when it reuses a live session before a turn. Before #21806 it restored the session's opened mode whenever the current mode differed from it, which is how a session reporting default got moved back to bypassPermissions. #21806 narrowed that to restoring only from plan (apps/server/src/orchestration-v2/Adapters/ClaudeAdapterV2.ts:9087-9103). The goal was to stop forcing bypass when Claude reports default because a settings policy disables it. Your sessions are opened with bypassPermissions and allowDangerouslySkipPermissions, which means T3 found no policy blocking bypass, but init still reports default. With the restore narrowed, nothing moves the session back to bypass, so every tool call asks.

This is separate from #22147, which is about switching a thread that's already running. Accepting this as a bug.

Ffeledori20d ago
Synced from GitHub

update, i found the real trigger. it's partly my setup.

my ~/.claude/settings.json sets CLAUDE_CODE_SUBPROCESS_ENV_SCRUB=1. with that set, the Claude CLI forces permission mode "default" at start and ignores --permission-mode. it prints:

⚠ Permission mode forced to default — CLAUDE_CODE_SUBPROCESS_ENV_SCRUB is set (allowed_non_write_users hardening). Declare allowedTools explicitly, or set CLAUDE_CODE_SUBPROCESS_ENV_SCRUB=0 to opt out.

up to nightly 20261019.3373, T3 sent query.set_permission_mode after the session start. that switched the mode to bypass and hid this. the 20261020 nightlies do not send it, so the forced default stays.

tested on claude 2.1.304:

  • scrub=1: --permission-mode bypassPermissions -> init permissionMode "default"
  • --settings '{"env":{"CLAUDE_CODE_SUBPROCESS_ENV_SCRUB":"0"}}': -> init permissionMode "bypassPermissions"

this is why my remote server works. it doesn't have the scrub setting.

what i'd still expect from T3:

  1. show the real mode. the composer says Full access while the CLI runs in default.
  2. either send set_permission_mode again after start, or warn when the CLI reports a different mode than the one the thread asked for.

i'm removing the scrub setting locally as a workaround.

Ddiederikh20d ago
Synced from GitHub

I have the same issue with 0.1.2-nightly.20261021.3457 and claude code 2.1.306. I have no scrub settings set.