Tool approvals sometimes silently lost when copilot CLI is used in parallel sessions

[brycecutt-msft]

Describe the bug

When two or more copilot CLI 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 entire locations object 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:

1. Open two terminals.
2. In Terminal A: cd <dirA>, run copilot, trigger a tool that prompts for approval (e.g., any shell command), choose Always allow. Leave the session running.
3. In Terminal B: cd <dirB> (a different directory), run copilot, trigger a tool that prompts for approval, choose Always allow. Exit the session.
4. Back in Terminal A: trigger another tool that prompts for approval, choose Always allow. Exit the session.
5. Inspect ~/.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-disk locations object with its in-memory copy — which never knew about <dirB>.

Expected behavior

locations in permissions-config.json should 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

• OS: Windows 11
• CPU architecture: x86_64
• Terminal emulator: Windows Terminal
• Shell: PowerShell 7
• Multiple parallel CLI sessions across different cwds (worktrees, separate projects) is the normal workflow that triggers this.

[rpelevin]

I would handle this as multi-writer permission state, not only as an approval UX bug.

permissions-config.json is effectively a durable authority ledger. If each CLI session rewrites the whole locations object 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:

1. two parallel sessions approving tools in different directories preserve both locations entries.
2. two sessions updating different tools in the same directory merge by tool/prefix key.
3. same key with different decisions resolves deterministically or forces a retry, not silent overwrite.
4. interrupted write cannot truncate or replace the config with a partial snapshot.
5. trustedFolders uses 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.

[BGMLAI]

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.