Copilot CLI unusable after macOS update/reboot because `.mcp-writer.binding` persists stale filesystem device ID

[erebor]

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:

{"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:

{"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.