Describe the bug
On exit, an interactive session writes its in-memory (launch-time) top-level model value back to ~/.copilot/settings.json. If settings.json was changed after that session launched - by a manual edit, or by another session that is still open - the exiting session's write silently reverts the file to its own older value.
When the persisted model is one that is no longer in the account's catalog, this becomes a self-perpetuating loop: a clean launch falls back to the built-in default, and closing any older session re-writes the stale id back to disk, so hand-editing settings.json never sticks.
This is distinct from #4067 (model not applied on startup). Here the value IS applied on a clean startup; it is later clobbered on session exit.
Affected version
1.0.75 (macOS, Darwin arm64)
Steps to reproduce
- Set
~/.copilot/settings.json to "model": "<model-A>" (any model; the loop is most visible if A is an id no longer in your catalog).
- Launch session S1: run
copilot (bare). It reads model A. Leave it open.
- Edit
~/.copilot/settings.json to "model": "<model-B>" (a different valid model). Confirm the on-disk value is B.
- Exit S1 (Ctrl-C twice, or
exit).
- Re-read
~/.copilot/settings.json: the value has reverted to A. B is gone.
If A is not in the catalog, the startup log for step 2 shows:
[WARNING] Model '<model-A>' from config file is unsupported or unknown. Falling back to default.
[INFO] Using default model: <default>
The exit in step 4 rewrites <model-A> (the launch-time value), not the resolved default, so the invalid id is preserved and the loop repeats on the next launch.
Expected behavior
- Exiting a session should not overwrite
settings.json with its launch-time model unless the user explicitly changed the model in that session (via /model).
- Edits made to
settings.json while a session is open should not be silently discarded when that session exits.
- A
model value that resolved to a fallback should not be re-persisted verbatim; persist the resolved model, or leave the file untouched.
Impact
- Hand-editing
settings.json to pin a default appears to "not work", because a lingering session overwrites it on exit.
- With a retired or unknown model id persisted, every new session silently downgrades to the default, and the file cannot be corrected while any older session is still alive.
Workaround
Pass the model explicitly at launch so it does not depend on the file:
copilot --model <model> --context <default|long_context> --effort <level>
A shell function wrapping copilot to always pass these flags is immune to the write-back.
Additional context
Describe the bug
On exit, an interactive session writes its in-memory (launch-time) top-level
modelvalue back to~/.copilot/settings.json. Ifsettings.jsonwas changed after that session launched - by a manual edit, or by another session that is still open - the exiting session's write silently reverts the file to its own older value.When the persisted
modelis one that is no longer in the account's catalog, this becomes a self-perpetuating loop: a clean launch falls back to the built-in default, and closing any older session re-writes the stale id back to disk, so hand-editingsettings.jsonnever sticks.This is distinct from #4067 (model not applied on startup). Here the value IS applied on a clean startup; it is later clobbered on session exit.
Affected version
1.0.75 (macOS, Darwin arm64)
Steps to reproduce
~/.copilot/settings.jsonto"model": "<model-A>"(any model; the loop is most visible if A is an id no longer in your catalog).copilot(bare). It reads model A. Leave it open.~/.copilot/settings.jsonto"model": "<model-B>"(a different valid model). Confirm the on-disk value is B.exit).~/.copilot/settings.json: the value has reverted to A. B is gone.If A is not in the catalog, the startup log for step 2 shows:
The exit in step 4 rewrites
<model-A>(the launch-time value), not the resolved default, so the invalid id is preserved and the loop repeats on the next launch.Expected behavior
settings.jsonwith its launch-time model unless the user explicitly changed the model in that session (via/model).settings.jsonwhile a session is open should not be silently discarded when that session exits.modelvalue that resolved to a fallback should not be re-persisted verbatim; persist the resolved model, or leave the file untouched.Impact
settings.jsonto pin a default appears to "not work", because a lingering session overwrites it on exit.Workaround
Pass the model explicitly at launch so it does not depend on the file:
A shell function wrapping
copilotto always pass these flags is immune to the write-back.Additional context
/modelpicker also writes the top-levelmodeland can resetcontextTier/effortLevelto undefined, so using it interacts with the same persisted field.modelfield insettings.jsonis not applied on startup; sessions fall back to defaultclaude-sonnet-5#4067 (model not applied on startup), contextTier setting (e.g. long_context) is not restored from settings.json on startup #3557 (contextTier not restored on startup), gpt-5-mini is not persistent set for future sessions #1869 (model not persistent for future sessions).