Skip to content

macOS: preserve Codex sessions and recover stale watcher locks - #17

Draft
arkgum wants to merge 3 commits into
dazer1234:mainfrom
arkgum:fix/macos-session-preserving-watcher
Draft

arkgum wants to merge 3 commits into
dazer1234:mainfrom
arkgum:fix/macos-session-preserving-watcher

Conversation

@arkgum

@arkgum arkgum commented Oct 13, 2026

Copy link
Copy Markdown

A normal Codex launch, an app update, or a lost debugging bridge can make the macOS watcher terminate an active session while attempting recovery. This change makes the watcher passive: it preserves every running session, waits while Codex is closed, and reconnects when a healthy bridge becomes available. Restarting an existing session remains an explicit manual operation.

Related to #15. This is a draft: it addresses unwanted restarts and watcher lock failures, but does not restore full renderer controls on an ordinary launch without a debugging bridge.

Changes

  • Remove automatic recovery restarts and migrate saved watcher policy without carrying forward restart permissions. Log the missing-bridge condition once per process generation.
  • Validate watcher ownership by PID, process start time, and command. Preserve fresh incomplete locks, retain stale metadata during reclamation, and guard release with a unique ownership token. Concurrent stale-lock claimants share a non-empty quarantine destination so a late claimant cannot replace the winner's lock.
  • Cherry-pick @tqmane's shared app-shared-* event-bus discovery change from [fix] codex 26.924 on windows #16 (270e0c19bde2c18121c4a8c1cc5d8e8e01b02c59), preserving original authorship. The Windows activation changes from that PR are not included.
  • Add regression coverage for ordinary launches, bridge loss, replacement processes, saved-policy migration, reused PIDs, incomplete locks, and concurrent claimants, including four separate child processes. Native macOS lock tests skip on other platforms; pure policy tests remain portable.
  • Document the remaining normal-launch connectivity limitation and renderer validation boundary.

Validation

Development host: macOS 27.0.1, arm64, hardware model Mac16,8. Locally installed versions observed during diagnosis: Codex 26.1007.30912 and Stream Deck 7.5.0.

  • npm ci --ignore-scripts completed.
  • npm run check passed.
  • npm test: 141 passed, 0 failed, 1 skipped (Windows PowerShell self-test), 142 total.
  • npm run build and the bundled macOS launcher self-test passed.
  • npm run validate passed Stream Deck package validation.
  • npm run audit:release passed for all three artifact roots.
  • git diff --check passed.

These are isolated automated/build checks. The new branch has not received live renderer, physical Stream Deck, Windows, or multi-host end-to-end testing. No physical Stream Deck model is claimed as validated. The installed Codex application was not restarted or modified for these checks.

Remaining work before full normal-launch support

The current renderer bridge still requires a bridge-enabled Codex process. This PR deliberately leaves a normal unbridged session disconnected rather than treating missing connectivity as permission to restart it. A normal-launch transport needs separate implementation and live validation; no hotkey or task-database fallback is introduced here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants