### Describe the bug Immediately after installing the latest macOS security update and rebooting, all Copilot CLI sessions—both newly started sessions and resumed existing sessions—became unable to process prompts. ### Affected version GitHub Copilot CLI 1.0.90-3. ### Steps to reproduce the behavior ## Environment - macOS Golden Gate 27.0.1 on Apple Silicon - GitHub Copilot CLI reports version 1.0.90-3 ## What Happened On startup after installing 27.0.1, I restarted my copilot sessions, and each of them reported: `Failed to start MCP Servers: Error: The shared writer lock or its directory changed.` Attempts to send prompts then hung/failed. Copilot logs repeatedly contained: `Scheduled queue processing failed; retrying once {"error":"Message(\"The shared writer lock or its directory changed.\")"}` and: `Scheduled queue processing failed after retry; queue drain abandoned {"error":"Message(\"The shared writer lock or its directory changed.\")"}` ## Root cause `~/.copilot/.mcp-writer.binding` contained persisted Unix filesystem identities: ```json {"root":{"platform":"unix","device":16777230,"inode":1767102}, "lock":{"platform":"unix","device":16777230,"inode":45460913}} ``` After the macOS update/reboot, `stat` showed: ~/.copilot: device=16777232 inode=1767102 ~/.copilot/.mcp-writer.lock: device=16777232 inode=45460913 Thus, the inode numbers remained exactly the same, but macOS had changed the filesystem device ID from 16777230 to 16777232. Copilot apparently interprets this change in device ID as indicating that the shared-writer lock or its directory has been replaced/changed, even though these are the same filesystem objects. The stale device ID appeared only in `.mcp-writer.binding`. ## Attempted workaround Moving `.mcp-writer.binding` aside did not cause Copilot to regenerate it. Instead, a newly launched Copilot reported: `Failed to start MCP Servers: Error: Shared writer storage I/O failed.` and attempts to send requests failed with: `Request session.send failed with message: Shared writer storage I/O failed.` Restoring the binding file returned behavior to the original "shared writer lock or its directory changed" failure. ## Successful workaround After backing up `.mcp-writer.binding`, I changed only the two persisted device IDs from: `16777230` to the device ID currently reported by stat: `16777232` producing: ```json {"root":{"platform":"unix","device":16777232,"inode":1767102}, "lock":{"platform":"unix","device":16777232,"inode":45460913}} ``` I then launched a new copilot process. MCP startup succeeded immediately and Copilot processed prompts normally. At this point, running `\restart` in the existing copilot sessions allowed them to recover as well (prior to fixing the device id, `/restart` had gone right back to the same broken condition). ### Expected behavior A macOS update/reboot that changes the filesystem device ID should not permanently prevent Copilot from starting its shared-writer storage. Copilot should either: 1. tolerate a device-ID change when it can otherwise safely establish the identity/integrity of the shared storage, or 2. safely regenerate/rebind .mcp-writer.binding when the stored filesystem identity becomes stale. In particular, removing a stale binding currently appears to make recovery worse because Copilot fails with Shared writer storage I/O failed rather than rebuilding the binding. ### Additional context This effectively disables all Copilot CLI sessions after the OS update, including existing/resumable sessions, until the undocumented .mcp-writer.binding file is manually repaired.