Describe the bug
When a trusted folder path contains a backslash followed by . (e.g., C:\Users\cormiej\.copilot) or a backslash followed by L (e.g., C:\Users\cormiej\AppData\Local\<anything>), Copilot CLI silently corrupts the entry the next time it rewrites ~/.copilot/config.json. Result: the agent re-prompts for permission to access these folders even though /list-dirs reports them as trusted.
Observed corruption (real example from my config.json):
"trustedFolders": [
"C:\\Projects",
"C:\\Repositories",
"C:\\Users\\cormiejcopilot", <- was "C:\\Users\\cormiej\\.copilot"
"C:\\Users\\cormiej\\AppDataocal\\genie_talend_converter", <- was "C:\\Users\\cormiej\\AppData\\Local\\genie_talend_converter"
"C:\\Users\\cormiej"
]
Notice the boundaries that collapsed: cormiej + copilot (lost \.) and AppData + ocal (lost \L).
Root cause hypothesis: the writer that updates trustedFolders is double-decoding or applying JSON-escape logic to an already-decoded string, so:
\\ decodes to \, then on re-encode \. is treated as an invalid escape, the \ is silently dropped, and the boundary between adjacent path segments collapses.- Same fault for
\L (which follows the same code path through whatever escape table — possibly adjacent to the legitimate \b, \f, \n, \r, \t, \u cases).
Pattern: any trusted folder whose next path segment starts with ., L, or potentially b, f, n, r, t, u is at risk. Folders not affected: C:\Projects, C:\Repositories, C:\Users\cormiej (no problematic next char following a backslash).
Impact: users who have a permission "always" approved watch it silently lapse and re-prompt indefinitely. Mitigation requires hand-editing config.json. The same corruption recurs after the next /add-dir.
Workaround: trust a parent path with no problematic next segment (e.g., trust C:\Users\cormiej instead of C:\Users\cormiej\.copilot). Confirms the trust check itself is functional; the bug is purely in path serialization.
Describe the bug
When a trusted folder path contains a backslash followed by
.(e.g.,C:\Users\cormiej\.copilot) or a backslash followed byL(e.g.,C:\Users\cormiej\AppData\Local\<anything>), Copilot CLI silently corrupts the entry the next time it rewrites~/.copilot/config.json. Result: the agent re-prompts for permission to access these folders even though/list-dirsreports them as trusted.Observed corruption (real example from my
config.json):Notice the boundaries that collapsed:
cormiej+copilot(lost\.) andAppData+ocal(lost\L).Root cause hypothesis: the writer that updates
trustedFoldersis double-decoding or applying JSON-escape logic to an already-decoded string, so:\\decodes to\, then on re-encode\.is treated as an invalid escape, the\is silently dropped, and the boundary between adjacent path segments collapses.\L(which follows the same code path through whatever escape table — possibly adjacent to the legitimate\b,\f,\n,\r,\t,\ucases).Pattern: any trusted folder whose next path segment starts with
.,L, or potentiallyb,f,n,r,t,uis at risk. Folders not affected:C:\Projects,C:\Repositories,C:\Users\cormiej(no problematic next char following a backslash).Impact: users who have a permission "always" approved watch it silently lapse and re-prompt indefinitely. Mitigation requires hand-editing
config.json. The same corruption recurs after the next/add-dir.Workaround: trust a parent path with no problematic next segment (e.g., trust
C:\Users\cormiejinstead ofC:\Users\cormiej\.copilot). Confirms the trust check itself is functional; the bug is purely in path serialization.