Session exit writes launch-time `model` back to settings.json, silently reverting edits (self-perpetuating stale default)
还没有人认领这个 Issue。
- 主要语言
- Shell
- 星标
- 11.2k
- 派生
- 1.9k
- 平均合并
- 14 小时 16 分钟
- 30 天内合并 PR
- 6
描述
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.jsonto"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.jsonto"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.jsonwith its launch-time model unless the user explicitly changed the model in that session (via/model). - Edits made to
settings.jsonwhile a session is open should not be silently discarded when that session exits. - A
modelvalue that resolved to a fallback should not be re-persisted verbatim; persist the resolved model, or leave the file untouched.
Impact
- Hand-editing
settings.jsonto 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
- The
/modelpicker also writes the top-levelmodeland can resetcontextTier/effortLevelto undefined, so using it interacts with the same persisted field. - Related: #4067 (model not applied on startup), #3557 (contextTier not restored on startup), #1869 (model not persistent for future sessions).
贡献指南
从这里开始
- 先读完整个 Issue,再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库,在一个分支上完成修改。
- 提交 Pull Request,并在描述里引用这个 Issue 编号。
调研方向
从将顶层模型写入 ~/.copilot/settings.json 的会话退出路径开始,然后将其与 /model 选择器的持久化行为进行比较。重现 issue 中的 S1/edit/exit 序列,并验证未发生更改的会话不再丢弃编辑内容,同时显式的 /model 更改仍会持久化预期值。
由索引模型根据 Issue 内容生成。
评估
- 领域
- cli
- Issue 类型
- 缺陷
- 难度
- 4/5
- 预计耗时
- 3-5 天
- 活跃度
- 活跃
- 描述清晰度
- 基本清楚
- 新手友好度
- 55/100