Describe the bug
When ~/.copilot/settings.json contains a valid, account-enabled top-level "model" value, the CLI does not apply it at startup. Sessions resolve to the built-in default claude-sonnet-5 instead. This is the same top-level model key that the in-app /model picker writes (verified by format, plain model id), so it would be expected to load on startup.
This differs from #3481 and closed #3557, which concern contextTier not being restored. Notably, #3557's description asserts "the model field is loaded correctly" — on 1.0.69 that is not the case. I have not determined when this broke, so I'm not claiming a regression, only current behavior.
Affected version
1.0.69 (macOS, Darwin arm64)
Steps to reproduce the behavior
- Edit
~/.copilot/settings.json to include "model": "claude-opus-4.8" (matches the format the /model picker writes; I hand-edited it — I did not separately test the picker-save-then-restart path).
- From a clean shell, run
copilot (bare, no flags). Also reproduces with -p and -i.
- Observe the resolved model via the log line
Using default model: claude-sonnet-5, or assistant_usage_events in ~/.copilot/session-store.db.
Expected behavior
Session starts on claude-opus-4.8.
Actual: session starts on claude-sonnet-5.
Additional context
copilot --model claude-opus-4.8 and COPILOT_MODEL=claude-opus-4.8 copilot both correctly run Opus, so the model is enabled/available on the account; only the settings.json path is skipped.
- Not a write race:
settings.json md5/mtime are unchanged across launches.
- Reproduced under a fully sanitized environment (
env -i), and in both interactive and -p modes.
- Inferred (from decompiled
app.js, not confirmed at runtime): the resolver considers --model > session model > COPILOT_MODEL > settings.json model > default, and the config tier appears skipped, landing on the default claude-sonnet-5. Treat this as a hypothesis, not a verified execution path.
Describe the bug
When
~/.copilot/settings.jsoncontains a valid, account-enabled top-level"model"value, the CLI does not apply it at startup. Sessions resolve to the built-in defaultclaude-sonnet-5instead. This is the same top-levelmodelkey that the in-app/modelpicker writes (verified by format, plain model id), so it would be expected to load on startup.This differs from #3481 and closed #3557, which concern
contextTiernot being restored. Notably, #3557's description asserts "themodelfield is loaded correctly" — on 1.0.69 that is not the case. I have not determined when this broke, so I'm not claiming a regression, only current behavior.Affected version
1.0.69 (macOS, Darwin arm64)
Steps to reproduce the behavior
~/.copilot/settings.jsonto include"model": "claude-opus-4.8"(matches the format the/modelpicker writes; I hand-edited it — I did not separately test the picker-save-then-restart path).copilot(bare, no flags). Also reproduces with-pand-i.Using default model: claude-sonnet-5, orassistant_usage_eventsin~/.copilot/session-store.db.Expected behavior
Session starts on
claude-opus-4.8.Actual: session starts on
claude-sonnet-5.Additional context
copilot --model claude-opus-4.8andCOPILOT_MODEL=claude-opus-4.8 copilotboth correctly run Opus, so the model is enabled/available on the account; only thesettings.jsonpath is skipped.settings.jsonmd5/mtime are unchanged across launches.env -i), and in both interactive and-pmodes.app.js, not confirmed at runtime): the resolver considers--model> session model >COPILOT_MODEL>settings.jsonmodel > default, and the config tier appears skipped, landing on the defaultclaude-sonnet-5. Treat this as a hypothesis, not a verified execution path.