Describe the feature or problem you'd like to solve
--max-autopilot-continues (default 5) is the only control over how long autopilot keeps going, but it is launch-flag-only: there is no settings.json key, no environment variable, and no way to change it once a session has started. Long-running autopilot work therefore stops at 5 continuations unless you remember the flag at launch — and when it does stop, there is no way to raise it without restarting the CLI and losing the session.
Proposed solution
Two related changes, either of which is useful on its own:
1. A persistable setting (maxAutopilotContinues)
Add a settings.json / config.json key so the default can be set once, with --max-autopilot-continues still overriding it per-invocation.
Today the value is registered in the arg parser with a hardcoded default and read only from the parsed CLI options object:
new Option("--max-autopilot-continues <count>", "Maximum number of continuation messages in autopilot mode")
.default(5)
Confirmed absent from copilot help config (no settings key) and copilot help environment (no env var). The only workaround is shadowing the launcher with a shell wrapper that injects the flag:
function copilot {
$copilotArgs = @($args)
if (-not ($copilotArgs | Where-Object { $_ -like '--max-autopilot-continues*' })) {
$copilotArgs += @('--max-autopilot-continues', 50)
}
& $RealCopilotShim @copilotArgs
}
That works, but it is per-shell (breaks if you launch from a different shell), invisible to anyone reading their config, and easy to forget on a new machine.
This is the same "hardcoded constant → user-settable key" shape as #1688 (configurable auto-compaction threshold), and #3977 established the precedent of adding a settings.json key for autopilot behavior — that one shipped as stayInAutopilot, which persists the mode but not the continuation cap.
2. Runtime adjustment via /limits
Make the cap changeable mid-session, e.g. /limits set max-autopilot-continues <n>.
This is the more valuable half. The value is currently read once at session construction and threaded through to the continuation decision, so when autopilot halts at the limit the session is stuck — the only recovery is restarting and losing accumulated context.
/limits is already the natural home for this: it lets you raise max-ai-credits live, and the limit-reached message already tells you to "increase or unset the session limit before trying again." Hitting the autopilot cap should offer the same recovery, ideally with an inline prompt to extend when the limit is reached.
Example prompts or workflows
- Long refactor —
/plan a large migration, choose "Accept plan and build on autopilot", walk away. It stops after 5 continuations with most todos still pending; restarting to pass a flag discards the plan context.
- Set once, forget — put
"maxAutopilotContinues": 50 in settings.json alongside stayInAutopilot, instead of maintaining a shell wrapper on every machine.
- Recover in place — autopilot stops at the cap with 3 todos left; run
/limits set max-autopilot-continues 40 and resume, rather than restarting.
- Fleet runs —
/fleet orchestration dispatches subagents across many todos and legitimately needs more continuations than a single-file edit; today both share the same default of 5.
- Cost control that actually fits — raise the continuation cap while relying on
--max-ai-credits as the real spend guardrail, instead of using a low continuation count as a proxy for budget.
Additional context
Describe the feature or problem you'd like to solve
--max-autopilot-continues(default5) is the only control over how long autopilot keeps going, but it is launch-flag-only: there is nosettings.jsonkey, no environment variable, and no way to change it once a session has started. Long-running autopilot work therefore stops at 5 continuations unless you remember the flag at launch — and when it does stop, there is no way to raise it without restarting the CLI and losing the session.Proposed solution
Two related changes, either of which is useful on its own:
1. A persistable setting (
maxAutopilotContinues)Add a
settings.json/config.jsonkey so the default can be set once, with--max-autopilot-continuesstill overriding it per-invocation.Today the value is registered in the arg parser with a hardcoded default and read only from the parsed CLI options object:
Confirmed absent from
copilot help config(no settings key) andcopilot help environment(no env var). The only workaround is shadowing the launcher with a shell wrapper that injects the flag:That works, but it is per-shell (breaks if you launch from a different shell), invisible to anyone reading their config, and easy to forget on a new machine.
This is the same "hardcoded constant → user-settable key" shape as #1688 (configurable auto-compaction threshold), and #3977 established the precedent of adding a
settings.jsonkey for autopilot behavior — that one shipped asstayInAutopilot, which persists the mode but not the continuation cap.2. Runtime adjustment via
/limitsMake the cap changeable mid-session, e.g.
/limits set max-autopilot-continues <n>.This is the more valuable half. The value is currently read once at session construction and threaded through to the continuation decision, so when autopilot halts at the limit the session is stuck — the only recovery is restarting and losing accumulated context.
/limitsis already the natural home for this: it lets you raisemax-ai-creditslive, and the limit-reached message already tells you to "increase or unset the session limit before trying again." Hitting the autopilot cap should offer the same recovery, ideally with an inline prompt to extend when the limit is reached.Example prompts or workflows
/plana large migration, choose "Accept plan and build on autopilot", walk away. It stops after 5 continuations with most todos stillpending; restarting to pass a flag discards the plan context."maxAutopilotContinues": 50insettings.jsonalongsidestayInAutopilot, instead of maintaining a shell wrapper on every machine./limits set max-autopilot-continues 40and resume, rather than restarting./fleetorchestration dispatches subagents across many todos and legitimately needs more continuations than a single-file edit; today both share the same default of 5.--max-ai-creditsas the real spend guardrail, instead of using a low continuation count as a proxy for budget.Additional context
stayInAutopilot, adjacent but different knob), Make Copilot Autopilot request-error retry count configurable #4210 (configurable autopilot retry count), Feature request: /config slash command — interactive editor for all writable settings (Claude Code parity) #3352 (/configeditor — would surface this key once it exists)--max-ai-credits, which is itself already session-settable via/limits— so the two controls are currently inconsistent in how they can be adjusted.