Repository navigation
Tool approvals sometimes silently lost when copilot CLI is used in parallel sessions #3563
Description
Activity
I would handle this as multi-writer permission state, not only as an approval UX bug.
permissions-config.jsonis effectively a durable authority ledger. If each CLI session rewrites the wholelocationsobject from its own in-memory snapshot, then a later "Always allow" can erase a different session's approval even though both user decisions were valid.Fields/state I would add around writes:
- config revision or mtime read by the session;
- atomic write temp path;
- per-location merge key;
- tool/prefix approval key;
- session id;
- decision timestamp;
- previous revision;
- write outcome: merged, retried, or conflict.
Acceptance tests:
- two parallel sessions approving tools in different directories preserve both
locationsentries. - two sessions updating different tools in the same directory merge by tool/prefix key.
- same key with different decisions resolves deterministically or forces a retry, not silent overwrite.
- interrupted write cannot truncate or replace the config with a partial snapshot.
trustedFoldersuses the same merge-safe config path if it has the same read-modify-write pattern.
That keeps "Always allow" as a real persisted decision instead of whichever session exits last.
This config store needs transactional updates. Each session should reread the latest file, merge only its own location entry, and write through an atomic replace guarded by a file lock or compare-and-swap generation. Preserving unknown keys is essential. Add a concurrency test with multiple processes approving different directories and barriers that force overlapping reads and writes; the final document must contain the union. It would also be useful to record last-writer metadata so support can distinguish corruption from an intentional removal.
Describe the bug
When two or more
copilotCLI sessions run simultaneously and each persists a tool approval (the "Always allow" prompt), one session's approval seems to sometimes silently overwrite the other's in~/.copilot/permissions-config.json. The loss is not limited to the same directory — approvals for other directories in the file can also be dropped, because the entirelocationsobject appears to be replaced rather than merged.This makes "Always allow" feel unreliable: user repeatedly re-approves the same commands, MCP tools, and extensions after seemingly random sessions.
The same read-modify-write pattern appears to be reused for other config files, so we suspect (but did not isolate repros for) related races affecting:
config.json→trustedFolders(re-prompted to trust folders that were previously trusted)Filing this against the most reproducible case; if the team confirms a shared root cause, fixing the underlying config store should resolve the others.
Affected version
1.0.55-7
Steps to reproduce the behavior
Seems intermittent but, variations of:
cd <dirA>, runcopilot, trigger a tool that prompts for approval (e.g., any shell command), choose Always allow. Leave the session running.cd <dirB>(a different directory), runcopilot, trigger a tool that prompts for approval, choose Always allow. Exit the session.~/.copilot/permissions-config.json.Observed:
locations[<dirB>]is missing entirely. Only Terminal A's view of the world survives, because Terminal A's final write replaced the on-disklocationsobject with its in-memory copy — which never knew about<dirB>.Expected behavior
locationsinpermissions-config.jsonshould contain entries for both<dirA>and<dirB>, with the approvals granted in each session preserved. Concurrent sessions should merge their changes, not overwrite each other.Additional context
Environment