[Bug]: New Pi threads fall back to Supervised when the default permission mode is Auto #30538

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/web

Steps to reproduce

1. In Settings, set the default permission mode for new threads to Auto. I keep it there for Codex and Claude.
2. Start a new thread and pick a Pi model.
3. Look at the composer's permission picker, then send a message that runs a command.

Expected behavior

Pi doesn't offer Auto. Its supportedRuntimeModes are approval-required, auto-accept-edits and full-access. A new Pi thread should step down to the broadest mode Pi offers, as delegate_task (#18065) and t3_thread_launch (#26682) already do. That would be Auto-accept edits. Better still, I could choose the mode Pi falls back to.

Actual behavior

The new Pi thread falls back to Supervised and asks for approval on every command. To avoid that, I have to switch the mode by hand on every Pi thread, or change the environment default to Full access, which also applies to every other provider.

The fallback picks the first supported mode instead of stepping down:

• web: resolveCompatibleRuntimeMode in apps/web/src/components/chat/runtimeModeConfig.ts returns modes[0] (approval-required)
• server: providerRuntimeMode in apps/server/src/orchestration-v2/RuntimePolicy.ts returns "approval-required"

Impact

Minor bug or occasional failure

Version or commit

T3 Code 0.1.6; same code on main @ 87f3d93

Environment

Linux (Ubuntu, kernel 6.8), Pi provider (pi 1.5.0)

Workaround

Pick Full access or Auto-accept edits by hand on each new Pi thread.

Related

• Ideas discussion Per-provider default permission mode, applied when switching models #17125 (per-provider default permission mode) covers the more general fix of letting each provider have its own default.