[Bug]: Claude "full access" fails to start when bypassPermissions is disabled by policy

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

Any Claude setup where permissions.disableBypassPermissionsMode is "disable" — either in a user settings.json or pushed down by a managed/enterprise policy — will hit this.

1. Set permissions.disableBypassPermissionsMode: "disable" in Claude settings (or have it enforced by a managed policy).
2. Start a Claude Agent thread and pick the "full access" runtime mode.
3. Send a message.

In ClaudeAdapter.startSession, "full access" maps straight to Claude's bypassPermissions permission mode. The adapter never checks whether that mode is actually allowed, so it hands bypassPermissions to the SDK/CLI even when the resolved settings forbid it. The CLI then refuses to run and the session dies on start.

I've patched this locally: when full access is requested I resolve the same settings cascade the CLI reads (resolveSettings over CLAUDE_SETTING_SOURCES), and if disableBypassPermissionsMode is "disable" I downgrade the effective mode to auto before starting, log a warning, and keep both the requested and effective mode on the span. It fails closed — if settings resolution throws I treat bypass as disabled and drop to auto rather than risk bypassing a managed lock.

That downgrade is really just a safety net though. The better fix is in the UI: if the policy forbids bypass, full access shouldn't be selectable at all — grey it out and make auto the default. For that the server needs to surface "bypass is disabled" in the provider state so apps/web can read it and disable the option instead of offering something that can't work.

Expected behavior

When the policy forbids bypassPermissions, the "full access" option is greyed out / disabled in the runtime mode picker and auto is the default. You never get to pick full access in an environment where it can't run. The server-side downgrade to auto stays as a backstop for cases where the client doesn't know (or policy changes mid-session).

Actual behavior

Full access is offered and selectable, then the session errors out at start because the CLI rejects bypassPermissions. It's unusable anywhere bypass mode is locked, even though auto would have worked fine.

Impact

Major degradation or frequent failure

Version or commit

main @ b125b7635

Environment

apps/server, Claude Agent provider. Happens wherever Claude settings or a managed policy set permissions.disableBypassPermissionsMode: "disable" — config-dependent, not tied to an OS.

Logs or stack traces

Screenshots, recordings, or supporting files

No response

Workaround

Pick the auto runtime mode instead of full access.

Start in apps/server at ClaudeAdapter.startSession and trace resolveSettings with CLAUDE_SETTING_SOURCES, then inspect the provider state consumed by apps/web's runtime mode picker. Done means full access is unavailable and auto is the default when bypassPermissions is disabled, while the server safely downgrades unsupported requests and records the requested and effective modes.