[Bug] Chrome extension pairing requires re-selection after container rebuild despite valid persisted device ID

Bug Description
Subject: Containerized Claude Code requires browser re-selection on every container rebuild despite valid persisted pairing

Environment:

• Claude Code 2.1.167 (native installer)
• VS Code Dev Container on macOS host (OrbStack runtime, Ubuntu 24.04 base)
• Launch pattern: claude --remote-control --chrome

Observed behavior:
After each Dev Containers: Rebuild Container operation, launching with --chrome shows the "Claude in Chrome" setup panel with "Extension: Not detected", requiring manual arrow-down to "Select browser…" to re-pick my paired browser — even when the pairing is correctly persisted on disk.

Empirical evidence the pairing IS persisted:
After rebuild, before re-selection, ~/.claude.json contains:
"chromeExtension": {
"pairedDeviceId": "<redacted>",
"pairedDeviceName": "<redacted>"
}
The deviceId is identical to the previous session's. The Welcome back greeting confirms claude.ai recognizes the user. Yet --chrome treats the bridge as not established and requires re-selection. After re-selection, the file contains the SAME deviceId — meaning re-selection isn't minting a new pairing, just refreshing some lifecycle marker.

Hypothesis:
The "do I need to re-pair?" check uses a signal beyond ~/.claude.json content — perhaps container session ID, runtime fingerprint, or server-side validation against an active session token. Whatever the signal is, persisting the file via named-volume backup-and-restore doesn't satisfy it.

Requests (any one would help):

1. Recognize an existing chromeExtension.pairedDeviceId in ~/.claude.json as valid on launch, when the device is reachable, without forcing a re-selection.
2. Add a --chrome-device-id <id> CLI flag for non-interactive selection at launch.
3. Add chromeExtension.pairedDeviceId to the documented settings.json schema as a stable user-configurable key.
4. Document the re-pairing lifecycle so containerized users can build appropriate persistence workarounds.

Why this matters:
Container rebuilds are routine for Dev Container users; persistence across rebuilds is the primary value proposition of named-volume mounts. The chrome re-pair adds ~5 seconds per rebuild and is the only remaining "redo this on every rebuild" step in our setup after we landed file-restore for ~/.claude.json. It's the highest-friction remaining issue in an otherwise fully-persistent containerized workflow.

Environment Info

• Platform: linux
• Terminal: vscode
• Version: 2.1.167
• Feedback ID: 1f688c6e-3753-47ea-88d1-e512ad2315ae

Errors

[]