Synced from GitHub
This also happens using the normal T3 app. It happened to me after updating to the latest version, 0.0.45.
[Bug]: Full access always fails for Claude when the T3 server runs as root#15882
Before submitting
- I searched existing issues and did not find a duplicate.
- I included enough detail to reproduce or investigate the problem.
Area
apps/server
Steps to reproduce
- Run the t3 server as root on Linux (here:
t3 connect+ background service on Ubuntu 24.04). - Install and log in to Claude Code as root on that machine.
- Open a Claude thread on that environment with mode Full access and send any message.
Expected behavior
Either Full access is shown as unavailable for Claude on a root environment, or the turn fails with the CLI's own explanation.
Actual behavior
The turn fails with only:
| 1 | turn/setPermissionMode failed |
| 2 | Claude runtime stream failed. |
Retrying in the same thread, even after switching to Auto, then fails every time with No conversation found with session ID: <uuid> (see #15854). A new thread in Auto, Auto-accept edits or Supervised works.
Cause: permissionModeForClaudeRuntimePolicy maps full-access to bypassPermissions (ClaudeAdapterV2.ts#L1440-L1486). Claude Code exits at startup when that mode is requested and the process uid is 0, unless IS_SANDBOX=1 is set or it's running under bubblewrap. So on a root host, Full access can never work for Claude, and nothing in the UI says why. Upstream context: anthropics/claude-code#58150.
Possible handling (no strong preference):
- Detect uid 0 on the server and mark Full access unavailable for Claude on that environment, with the reason.
- Or fall back to the closest mode that works as root and show a notice.
- At minimum, surface the CLI's message (#5943).
Setting IS_SANDBOX=1 automatically doesn't seem right, since it would switch off a safety check the user never agreed to.
Impact
Blocks work completely
Version or commit
t3 0.0.45 (server and macOS desktop app). Also checked main at 4ee6bfd5; there's no root handling there.
Environment
- Server: Ubuntu 24.04.4 LTS x86_64, running as root, t3 background service (systemd --user), reached via T3 Connect and a desktop SSH environment - Client: macOS desktop app 0.0.45 - Provider: Claude Code 2.1.289 (also reproduced on 2.1.276), Claude Max, Claude Sonnet 5.5
Logs or stack traces
shell
| 1 | $ claude -p "say hi" --permission-mode bypassPermissions |
| 2 | --dangerously-skip-permissions cannot be used with root/sudo privileges for security reasons |
Screenshots, recordings, or supporting files
Workaround
Use Auto, Auto-accept edits or Supervised, and start a new thread after a failed Full-access turn. Running t3 as a non-root user avoids it entirely. Based on the CLI's check, IS_SANDBOX=1 in the Claude provider's environment variables should also get past it (not tested, and it turns off that safety check).
Synced from GitHub
Still reproduces with the T3 server runtime installed under versions/0.1.2 and Claude Code 2.1.309 on Linux x86_64, running as root. Provider/model: Claude / claude-opus-5-5, Full access mode.
The UI reports only “Provider turn failed.” Two consecutive attempts failed immediately.
The provider event log shows these query options (unrelated fields omitted):
json
| 1 | { |
| 2 | "permissionMode": "bypassPermissions", |
| 3 | "allowDangerouslySkipPermissions": true, |
| 4 | "pathToClaudeCodeExecutable": "claude" |
| 5 | } |
The server log reports:
text
| 1 | orchestration-v2.claude-query-stream-failed |
| 2 | ClaudeAgentSdkQueryRunnerError: Claude Agent SDK query failed. |
| 3 | [cause]: Error: Claude Code process exited with code 1 |
Running a minimal CLI reproduction as the same root user exposes the actual cause:
console
| 1 | $ claude --dangerously-skip-permissions --print </dev/null |
| 2 | --dangerously-skip-permissions cannot be used with root/sudo privileges for security reasons |
Exit status: 1. No model request is needed to reproduce this startup refusal.
It would help to surface this underlying CLI error in the thread and explain that Full access is unavailable for Claude when running as root, instead of showing only “Provider turn failed.”
Synced from GitHub
Still reproduces on T3 server runtime 0.1.5 with Claude Code 2.1.314 (Linux x86_64, server running as root, model claude-opus-5-5).
The UI shows only "Provider error / Provider turn failed." It looked random at first ("works sometimes, fails when I open another session on the same repo"), but the provider event logs split cleanly by permission mode:
| Thread | permissionMode in query.open | incoming events | result |
|---|---|---|---|
983ac325… | bypassPermissions | 0 | failed (2 runs) |
a4e6ebc9… | bypassPermissions | 0 | failed (2 runs) |
66c95811… | bypassPermissions | 0 | failed |
2032b9bb… | bypassPermissions | 0 | failed |
41b271a4… | auto | 224 | worked |
812d6dde… | auto | 599 | worked |
So the "sometimes" is just which mode the new thread starts in. Existing threads were on Auto, and new ones opened in Full access.
What T3 stores for the failed turn (orchestration_v2_projection_turn_items):
json
| 1 | {"type":"error","title":"Provider error","status":"failed", |
| 2 | "failure":{"class":"transport_error","message":"Provider turn failed.","code":null,"retryable":null}} |
The CLI's own refusal message never reaches the UI or the trace. The only related line in server.trace.ndjson is a WARN on every failing ClaudeAgentSdkQueryRunner.open:
| 1 | orchestration-v2.claude-mcp-servers-unavailable { threadId: "983ac325-…", servers: ["t3-code"] } |
This looks like a side effect of the process exiting at startup, not a separate cause. It might be a useful hook for detecting the failure early.
Retrying in the same thread re-opens with resume: <sessionId> and fails the same way (as described in #15854). Switching a new thread to Auto works.
+1 to marking Full access unavailable for Claude when the server uid is 0, or at least showing the CLI's message (#26382 / #26082).