Skip to content

Use upstream's runtime-mode handling with a step-down fallback - #282

Merged
henrychu04 merged 1 commit into
coder-onlyfrom
t3code/runtime-modes-upstream
Oct 29, 2026
Merged

henrychu04 merged 1 commit into
coder-onlyfrom
t3code/runtime-modes-upstream

Conversation

@henrychu04

Copy link
Copy Markdown
Owner

The fork now uses upstream's runtime-mode handling. One small difference remains: a mode the workspace policy disallows steps down to the next lower allowed mode, where upstream drops to Supervised.

Why: the Fable review of the 67661cf → 6d450a4 sync found that pingdotgg#25869's new-thread permissions label used upstream's resolver while the composer used the fork's. The label could say "Full access" while the run got "Auto-accept edits". Rather than add another seam, this removes the fork's own mode logic.

Changes:

  • Provider-level modes. Claude (its disableAutoMode and disableBypassPermissionsMode policy) and Codex (configRequirements/read) report allowed modes through upstream's provider-level supportedRuntimeModes. If the policy can't be read, they offer only the safe modes.
  • Removed fork code:
    • per-model supportedRuntimeModes and CustomModelCapabilities (contracts and shared go back to upstream);
    • attachSupportedRuntimeModes;
    • the composer's resolveComposerRuntimeModes and its safe-modes-until-ready rule;
    • RuntimePolicy.modelRuntimeMode;
    • their fork-only tests.
  • One shared mode list. The composer, the new-thread label, RuntimePolicy and delegated tasks all read it with upstream's code.
  • Step-down rule. runtimeModeConfig.resolveCompatibleRuntimeMode and RuntimePolicy.providerRuntimeMode both step an unsupported mode down to the broadest offered mode below it, as upstream's delegatedTaskModes.resolveRuntimeMode already does. This is the only remaining delta, marked Coder: in both places.
  • Docs. docs/user/permission-modes.md describes the policy, the step-down, and the new-thread default setting. coder-only.md is updated.

Trade-off: while a provider is still probing, the composer shows all four modes. Once the policy is read, the list and the mode the run gets are correct.

Verification:

  • pnpm test:coder passes, except the known localApi load flake (Tests that flake under full-suite load #236), which passes alone.
  • pnpm build passes.
  • The typechecks for server, web, helper, contracts, shared, client-runtime, coder-cli and the provider packages pass.
  • pnpm knip:check, pnpm test:knip, vp fmt --check and the unused-locals check pass.
  • A throwaway test covered the step-down: Full access → Auto, Auto → Auto-accept edits, a mode below every allowed one → the lowest allowed, and no policy keeps the choice.
  • Not checked live: real Claude and Codex need quota in the harness workspaces. Upstream's own RuntimePolicy test passes unchanged.

🤖 Generated with Claude Code

Claude and Codex now report workspace policy through upstream's
provider-level supportedRuntimeModes instead of per-model capabilities,
so the composer, its new-thread permissions label, RuntimePolicy, and
delegated tasks all read the same list. The fork's per-model modes,
safe-modes-until-ready rule, CustomModelCapabilities contract, and
composer and server copies of the fallback are gone.

One delta remains: a mode the provider does not offer steps down to the
broadest offered mode below it, as upstream's delegated-task resolver
already does, instead of falling to Supervised. This also fixes the
new-thread permissions label, which used upstream's resolver while the
composer used the fork's.

permission-modes.md describes the policy, the step-down, and the
new-thread default setting.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant