fix(server): start Claude full access without forbidden permission modes (#4927)

[imMxts]

Fixes #4927

What Changed

Claude startSession now resolves the same filesystem settings cascade as the SDK session (user, project, local; managed policy still loads regardless) before requesting bypassPermissions or auto.

If resolved policy forbids the requested mode, the adapter:

• keeps the thread's requested runtime mode
• starts Claude in the next allowed mode: Auto if only bypass is locked, Supervised if Auto is locked too
• omits allowDangerouslySkipPermissions unless effective mode is still bypass
• records requested vs effective mode on the session span
• logs a warning without settings contents, paths, or credentials

Existing Full access behavior is unchanged when policy allows bypass. Auto-accept-edits and supervised keep their current mappings.

Settings resolve for isolated Claude homes temporarily sets CLAUDE_CONFIG_DIR under a process-wide mutex and always restores it, including when resolve throws. Tool auto-allow follows the effective Claude permission mode, not the requested Full access label.

Why

Verified root cause

On origin/main (bab4b6f02), ClaudeAdapter.startSession mapped "full-access" straight to permissionMode: "bypassPermissions" plus allowDangerouslySkipPermissions: true. It never read Claude's resolved policy. Current Claude docs say permissions.disableBypassPermissionsMode: "disable" (user settings or managed policy) forbids that mode. The adapter still sent it, so the Claude CLI/SDK rejected the session.

The first draft only remapped Full access to Auto. Claude also accepts disableAutoMode: "disable" (top-level or permissions.disableAutoMode). Sending Auto in that case is the same class of bug. Claude docs say a session that would start in Auto then starts in default / Manual instead.

Why this seam

Option	Verdict
UI-only disable of Full access	Rejected. Chat, compact menu, mobile sheets, command palette, and RPC can all still request the mode.
Shared server+UI policy contract	Rejected for this bug. No existing provider-state field for "bypass locked", and it would expand contracts/web/mobile.
Hard error instead of Auto	Weaker than the issue's working workaround. Auto already starts cleanly when it is allowed.
Server-side check in the Claude adapter	Selected. One Claude-only seam, same startSession public interface, strongest policy guarantee, UI can still be added later.

Requested vs effective mode

• Requested: session.runtimeMode stays what the client asked for (full-access or auto).
• Effective: claude.query.permission_mode is the allowed mode (bypassPermissions, auto, or omitted for Supervised); claude.query.requested_permission_mode keeps the original mapping.
• Plan-mode restore uses the effective base mode (auto, or default when Supervised).
• canUseTool auto-allows only when the effective mode is still bypassPermissions.

Tests and commands

vp test run apps/server/src/provider/Layers/ClaudeAdapter.test.ts
vp run --filter t3 typecheck
vp lint apps/server/src/provider/Layers/ClaudeAdapter.ts apps/server/src/provider/Layers/ClaudeAdapter.test.ts

88 tests passed. Typecheck passed. No new lint on the changed logic. No real Claude account, credentials, or managed policy required. Policy tests inject settings fixtures. CLAUDE_CONFIG_DIR tests inject the inner SDK resolve so they observe the env swap without hitting disk or MDM.

Covered matrix: permissive + full access; bypass locked + full access → Auto; bypass and Auto locked + full access → Supervised; Auto locked + Auto runtime → Supervised; Auto locked + full access still bypass; top-level and permissions.disableAutoMode; non-"disable" policy values; settings resolution failure (fail closed to Auto); plan restore after Auto or Supervised downgrade; resolve call uses cwd + ["user","project","local"]; instance CLAUDE_CONFIG_DIR is visible during resolve and restored after success or throw; process-wide config-dir lock; tools are not auto-allowed after a Supervised downgrade.

Risk, compatibility, and rollout

• Server-only safety backstop. Web, desktop, and mobile still offer Full access; the session no longer dies.
• resolveSettings() is an alpha Claude Agent SDK API. We call it with the same sources as query().
• Custom CLAUDE_CONFIG_DIR is applied around the in-process resolve call under a process-wide mutex so user settings from isolated Claude homes are visible. The SDK call itself stays interruptible; acquire/release restore the previous env.
• Resolve failure still fail-closes to Auto (the issue author's working workaround), not Supervised.
• No credentials or policy JSON are logged.

UI Changes

None. Composer, compact menu, and mobile still show Full access. A later change can grey it out once provider state surfaces "bypass locked".

Remaining uncertainty

• Current Claude CLI may silently remap bypass to default in some versions rather than hard-failing. Either way, T3 must not send the forbidden request.
• Whether Full access should snap the visible thread mode to Auto, stay as Full access, or become a hard picker error still needs a product call.
• UI disable across web, mobile, command palette, and defaults is intentionally out of scope.

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes
• I included a video for animation/interaction changes

Model: Cursor Grok 4.6. Harness: Cursor cloud agent.

Note

Fix Claude full-access sessions to start without forbidden permission modes

• When full-access mode requests bypassPermissions but policy has disabled it, the adapter now downgrades to auto; if auto is also disabled, it falls back to supervised (undefined) mode.
• Settings resolution uses a semaphore-guarded CLAUDE_CONFIG_DIR swap to safely serialize concurrent environment mutations.
• Resolution failures are treated as if bypass is disabled, falling back to CLAUDE_BYPASS_DISABLED_SETTINGS.
• Tool calls are auto-allowed only when the effective permissionMode is bypassPermissions; otherwise they require approval.
• Behavioral Change: startSession now resolves Claude policy settings and may silently downgrade the requested permission mode, logging a warning and annotating the span with both requested and effective modes.

^{Macroscope summarized 7278ed4.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 6ab8962b-58fc-4f3c-85a5-aaf223c62af7

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[macroscopeapp]

One finding on error modeling for the new ClaudeSettingsResolveError. Everything else (namespace imports, Semaphore usage, option-based test seams, warning-log payloads) matches the service conventions.

^{Posted via Macroscope — Effect Service Conventions}

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 2 potential issues.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

Want fixes drafted automatically? Bugbot Autofix can create code changes for findings. A team admin can enable Autofix in the Cursor dashboard.

^{Reviewed by Cursor Bugbot for commit 4fbcb8e. Configure here.}

[macroscopeapp]

Approvability

Verdict: Needs human review

This PR changes runtime behavior for permission mode selection when Claude policy forbids certain modes. It affects security-related functionality (bypass permissions, auto-approval behavior) and introduces new policy resolution logic. These substantive changes to permission handling warrant human review.

^{You can customize Macroscope's approvability policy. Learn more.}