config.json trustedFolders (and other managed state) lost when concurrent sessions overwrite the file on exit

[lonetwin]

Bug

~/.copilot/config.json (marked // This file is managed automatically.) is not merged/reconciled when written — each running Copilot CLI session appears to hold its own in-memory copy of the file's managed state (e.g. trustedFolders) and rewrites the entire file on exit using that stale snapshot. If a directory is added via /add-dir in one session while other sessions are still open, the addition is silently lost as soon as any of those other sessions closes and overwrites config.json with its older list.

This makes /add-dir (intended to persist trusted directories globally, per its own help text: "Allow file access to a directory and load its .github skills and agents as trusted configuration") effectively non-persistent whenever more than one CLI session/window is used at a time — which is a common workflow.

Steps to Reproduce

1. Open two Copilot CLI sessions (session A and session B) in different terminals.
2. In session A, run /add-dir /path/to/new-dir. Confirm ~/.copilot/config.json's trustedFolders now includes the new path.
3. Without closing session A, exit session B (ctrl+d or normal exit).
4. Inspect ~/.copilot/config.json again — the directory added in step 2 is gone, because session B rewrote the file from its own (older) in-memory state.

Expected Behavior

Writes to config.json (and similar "managed automatically" files, e.g. permissions-config.json) should be done as a read-modify-write with file locking, or by merging the specific keys being changed into the on-disk state, rather than replacing the whole file with a long-lived in-memory snapshot. At minimum, list-valued fields like trustedFolders should be unioned rather than overwritten.

Additional Context

• Copilot CLI version: 1.0.86
• Linux
• This looks like the same underlying root cause as Hooks in config.json are not preserved across session starts #3403 ("Hooks in config.json are not preserved across session starts") and is likely contributing to the repeated reports in Feature Request: Persist /add-dir allowed directories across sessions #2284 / Feature request: Persistent directory allow list across sessions #3050 / allowed_directories in permissions.config is never loaded #4398 that /add-dir/trusted-directory persistence "doesn't work" — in our case the user had run /add-dir on the same path "numerous times" and it kept reverting.
• Workaround: close all other Copilot CLI sessions before adding a directory, or edit ~/.copilot/config.json directly while no other sessions are running.

[lonetwin]

Correction / retraction of original report:

After further testing, my original reproduction steps and root-cause claim were incorrect, and I want to correct them rather than leave misleading info here:

1. trustedFolders in config.json governs workspace trust for MCP/skill/agent loading, not the /add-dir file-access allow-list shown by /list-dirs. These are two separate mechanisms — directories added via /add-dir are not written to trustedFolders at all in my testing, and adding a directory to /list-dirs's allow-list has no corresponding entry ever appearing in config.json. So /add-dir persistence is more accurately tracked by Feature Request: Persist /add-dir allowed directories across sessions #2284 / Feature request: Persistent directory allow list across sessions #3050 / allowed_directories in permissions.config is never loaded #4398 (feature requests for a currently-nonexistent persistence mechanism), not a corruption bug in config.json.

2. However, I did observe a separate, real issue with config.json itself: I manually added an entry to trustedFolders directly in the file. With no other Copilot CLI session open or closing, that manual edit was silently reverted a few minutes later, in the same single running session, after the file's mtime updated. This suggests the running process periodically rewrites config.json from an in-memory snapshot (likely taken at startup or on some internal state change), discarding any out-of-band edits to the file — not specifically tied to concurrent sessions closing, as I originally claimed.

So the actual, narrower bug is: config.json is periodically rewritten from an in-memory snapshot even within a single session, silently discarding any external/manual changes to the file since that snapshot was taken (not specifically a multi-session race). Apologies for the noise — happy to help narrow this down further if useful, otherwise feel free to close as a duplicate of #3403, which documents essentially the same overwrite-on-write behavior for the hooks key.