Live Bidirectional Auth Sync

Status: Deferred — design proposal, blocked on jackin❯ daemon production lifecycle/socket foundation. Plan 042 deliberately did not prototype live auth sync because it carries credentials and needs the daemon's redaction, coredump, version-skew, and lifecycle posture proven first; no implementation work has begun.

Shipped facts

jackin❯'s sync auth mode (AuthMode::Sync in crates/jackin-console/src/tui/auth.rs) reads the host login once per container launch, copies the token into the role-state directory, and bind-mounts it. That covers the first-launch convenience case only: a host token rotated while a container is running is never picked up, an in-container refresh never flows back to the host or to sibling containers, and two parallel containers sharing an account can invalidate each other's OAuth grant. Capsule's session-local usage/account snapshots are already flock-protected where they share state (Phase 2 of the auth reliability program), but that is launch-time and single-container scope, not live cross-process reconciliation.

This item is Phase 4 of the auth reliability and convenience program and depends entirely on the jackin❯ daemon, which does not exist yet — there is no long-running jackin❯ host process today. No adapter, shared store, or container-side watcher described below has been built.

Remaining work

1. jackin❯ daemon Phase 1 must ship first (lifecycle, install, control socket, log redaction, no watchers). This item cannot start before that. See jackin❯ daemon.
2. Per-axis adapter on the daemon's plug-in surface for gh, Claude, Codex, and future axes (Amp, etc.) — watches host token stores (inotify on Linux, polling on macOS) and reconciles a flock-protected shared store.
3. Container-side watcher — small static binary in the construct image, inotify on agent credential paths, pushes in-container refreshes to the shared store bind-mount.
4. macOS Keychain bridge — write refreshed tokens back to Keychain via security add-generic-password -U so the host user's normal gh / claude workflow stays consistent.
5. Conflict resolution — last-writer-wins by (mtime, checksum), with in-container rotation winning over a stale host poll landing in the same window; surfaced via jackin auth status (tracked under Auth health and operator visibility).
6. Naming decision — sync mode's current name describes launch-time snapshot behaviour, not the bidirectional meaning the word implies; a rename (candidates: forward or snapshot) should land in the same PR series as the live mode, not before.

Full architecture sketch, naming options, and host-write rationale: Live bidirectional auth sync — design rationale.

Out of scope

• SSH-key forwarding stays excluded. Authentication documents why.
• Cross-host sync (different operator machines sharing one store). The daemon is per-operator-user, per-host.
• Distributed conflict resolution beyond last-writer-wins.

Related work

• Auth reliability and convenience program — umbrella program that places live sync as Phase 4 in the complete auth fix sequence.
• jackin❯ daemon — umbrella item that introduces the long-running jackin❯ process this feature depends on.
• GitHub CLI authentication strategy — current sync mode lives here; "Bidirectional shared-store sync" was previously listed as a follow-up under that item, replaced by this dedicated roadmap item.
• Auth health and operator visibility — owns the jackin auth status subcommand this item's conflict surfacing depends on.
• Credential source pattern — future unified credential resolver; the daemon's per-axis adapter trait should be expressible inside it.
• Research: Live bidirectional auth sync — design rationale — naming analysis, architecture sketch, conflict resolution, host-write rationale.
• Reliable Claude authentication strategy — Claude axis design notes; live sync becomes the long-term answer to the concurrent-session token-drift concerns.
• jackin❯ Desktop Agent Hub — native account/status surface that would read live auth and quota state from the daemon first.