Preserve user OpenCode config in the bridge shadow dir

omoEnsureBridgeConfig now creates a fresh ~/.cmuxterm/omo-config containing only the bridge plugin, and runOMO later points OPENCODE_CONFIG_DIR at that directory, so existing user config (for example ~/.config/opencode/opencode.json model/provider/auth settings) is no longer visible in cmux omo. In environments that depend on non-default OpenCode configuration, this causes cmux omo to start with defaults or fail to authenticate, which is a functional regression from the previous behavior that layered the user config into the shadow directory.

Useful? React with 👍 / 👎.

TOCTOU: store.load() + store.mutate { $0 = staleState } defeats the file lock

All four subcommands (set-root, clear-root, spawn, delete) share the same broken pattern:

1. var state = try store.load() — acquires the lock, reads, then releases the lock
2. Local state is mutated
3. try store.mutate { $0 = state } — acquires the lock again, reads the current on-disk state into $0, but the closure immediately overwrites it with the stale state captured before the lock

Any write made by another omo-hook invocation between steps 1 and 3 is silently discarded. The mutate API is designed for atomic read-modify-write, but using { $0 = state } defeats that entirely.

The same pattern appears in:

• clear-root at lines 12499 + 12503
• spawn at lines 12527 + 12539 / 12546 / 12611 (three separate non-atomic mutations in a single subcommand invocation)
• delete at lines 12632 + 12634

The fix is to consolidate all modifications for each subcommand into a single store.mutate { state in ... } call, so no store.load() call is needed separately:

// set-root — correct pattern
var surfacesToClose: [String] = []
try store.mutate { state in
    if let existingRoot = state.rootSessionId, existingRoot != normalizedRoot {
        surfacesToClose = state.children.values.map(\.surfaceId)
        state.children.removeAll()
    }
    state.rootSessionId = normalizedRoot
}
// surface.close calls can happen after the atomic write

EXIT trap masks $cmux_omo_status — script always exits with 0

In POSIX sh (and bash), when exit N triggers an EXIT trap, the script's final exit code is the exit code of the last command in the trap handler, not N. Because cmux_omo_cleanup ends with || true, the EXIT trap always succeeds with status 0. The exit "$cmux_omo_status" line is therefore never effective — the child pane always exits with 0 regardless of opencode attach's outcome.

To preserve the exit status through the trap, capture it before the trap fires and restore it inside the handler:

let deleteCommand = "\(shellQuote(openCodeExecutablePath)) session delete \(shellQuote(sessionId)) >/dev/null 2>&1 || true"
scriptLines.append("cmux_omo_cleanup() { _rc=$?; \(deleteCommand); exit \"$_rc\"; }")
scriptLines.append("trap cmux_omo_cleanup EXIT")
scriptLines.append("\(shellQuote(openCodeExecutablePath)) attach \(shellQuote(serverURL)) --session \(shellQuote(sessionId))")

Using _rc=$? at the start of the trap captures the exit code that triggered the EXIT, then exit "$_rc" propagates it after cleanup. This also removes the redundant explicit exit "$cmux_omo_status" line and the HUP/INT/TERM signal registrations (since EXIT fires on those too in most POSIX shells).

Fragile shim-dir lookup via PATH suffix scan

The shim directory path is recovered by scanning PATH for an entry matching the hard-coded suffix /.cmuxterm/omo-bin. This will silently return nil if the entry appears with a trailing slash variant not covered by the two checks, or if a user's HOME is not a canonical path (e.g. via a symlink).

configureOMOEnvironment already calls setenv("CMUX_OMO_OPENCODE_BIN", ...) for the binary — a parallel CMUX_OMO_SHIM_DIR env var set alongside it would be cleaner and more reliable:

// in configureOMOEnvironment
setenv("CMUX_OMO_SHIM_DIR", shimDirectory.path, 1)

// in spawn
let shimDirectoryPath = env["CMUX_OMO_SHIM_DIR"]?
    .trimmingCharacters(in: .whitespacesAndNewlines)
    .nilIfEmpty

P1: Create the state directory before opening the OMO lock file. First-run cmux omo can fail because the lock path’s parent directory may not exist.

Check if this issue is valid — if so, understand the root cause and fix it. At CLI/cmux.swift, line 622:

<comment>Create the state directory before opening the OMO lock file. First-run `cmux omo` can fail because the lock path’s parent directory may not exist.</comment>

<file context>
@@ -514,6 +514,148 @@ private final class ClaudeHookSessionStore {
+
+    private func withLockedState<T>(_ body: (inout OMOBridgeStateFile) throws -> T) throws -> T {
+        let lockPath = statePath + ".lock"
+        let fd = open(lockPath, O_CREAT | O_RDWR, mode_t(S_IRUSR | S_IWUSR))
+        if fd < 0 {
+            throw CLIError(message: "Failed to open OMO bridge state lock: \(lockPath)")
</file context>

⚠️ Potential issue | 🔴 Critical

Create the state directory before opening the lock file.

Line 622 opens the .lock file before the new omo-state parent directory exists. saveUnlocked(_:) only creates that directory later, so the first reset() on a clean machine fails with ENOENT and cmux omo never starts.

     private func withLockedState<T>(_ body: (inout OMOBridgeStateFile) throws -> T) throws -> T {
         let lockPath = statePath + ".lock"
+        let lockURL = URL(fileURLWithPath: lockPath)
+        try fileManager.createDirectory(
+            at: lockURL.deletingLastPathComponent(),
+            withIntermediateDirectories: true,
+            attributes: nil
+        )
         let fd = open(lockPath, O_CREAT | O_RDWR, mode_t(S_IRUSR | S_IWUSR))
         if fd < 0 {
             throw CLIError(message: "Failed to open OMO bridge state lock: \(lockPath)")
         }

Verify each finding against the current code and only fix it if needed.

In `@CLI/cmux.swift` around lines 620 - 635, The lock file is opened before its
parent state directory exists which causes ENOENT on first run; in
withLockedState(_:) ensure the directory containing statePath exists before
calling open(lockPath,...). Create the parent directory (using
FileManager.createDirectory with intermediate directories true) for statePath or
lockPath, handle/throw any directory-creation errors, then proceed to open the
lock, call loadUnlocked(), run body(&state), and saveUnlocked(state) as before;
reference symbols: withLockedState(_:), statePath, lockPath, loadUnlocked(),
saveUnlocked().

⚠️ Potential issue | 🟠 Major

# Search for OpenCode CLI session delete implementation
git log --all --oneline --grep="session delete" 2>/dev/null | head -20 || echo "Git history unavailable"

# Check if there are any references to OpenCode CLI source in this repo
find . -type f -name "*.swift" -o -name "*.ts" -o -name "*.py" 2>/dev/null | head -10

# Search for session delete usage patterns in the codebase
rg "session delete" -t swift -t sh -t txt -A 5 -B 5 2>/dev/null | head -50

# Search for OPENCODE_PORT usage context
rg "OPENCODE_PORT" -t swift -A 3 -B 3 2>/dev/null | head -50

# Get full context around the deleteCommand and scriptLines building
sed -n '10200,10250p' CLI/cmux.swift

# Search for where launcherEnvironment or processEnvironment variables are exported to scriptLines
rg "scriptLines.append.*export" CLI/cmux.swift -B 3 -A 1 | head -60

# Check if there are any parameters or flags that can be passed to session delete in the code
rg "session delete" -B 10 -A 10 CLI/cmux.swift

# Check what serverURL is and where it comes from
rg "serverURL" CLI/cmux.swift | head -20

# Find where serverURL comes from and what it represents
rg "CMUX_OMO_SERVER_URL" CLI/cmux.swift -B 5 -A 5

# Check the full context of the function call to omoAttachCommand
rg "omoAttachCommand" CLI/cmux.swift -B 3 -A 3

Pass server URL to cleanup delete command to match attach target.

The cleanup trap calls session delete <id> without specifying a server URL, while attach explicitly targets serverURL. The child shell environment does not export CMUX_OMO_SERVER_URL or OPENCODE_PORT, so session delete cannot reliably target the same server that attach connected to. If the session was created on serverURL, but cleanup tries to delete it from a different server (inferred from OPENCODE_CONFIG_DIR alone), the cleanup silently succeeds without deleting the correct session, leaving orphans.

Export the server URL to the child shell or pass it directly to the delete command:

scriptLines.append("export CMUX_OMO_SERVER_URL=\(shellQuote(serverURL))")

and update the delete command to use it (e.g., via a wrapper or flag if session delete supports server targeting).

Verify each finding against the current code and only fix it if needed.

In `@CLI/cmux.swift` around lines 10224 - 10235, The cleanup currently builds
deleteCommand without the server target, so cmux_omo_cleanup may delete the
wrong session; export the server URL into the child shell and include it in the
delete invocation. Add an export for CMUX_OMO_SERVER_URL using the existing
serverURL (via shellQuote(serverURL)) before building deleteCommand, and update
deleteCommand (and the cmux_omo_cleanup wrapper) to pass that server target (or
rely on the exported CMUX_OMO_SERVER_URL) when invoking the executable at
openCodeExecutablePath to delete sessionId so it matches the attach call.

⚠️ Potential issue | 🟠 Major

Keep bridge-state updates inside one lock scope.

These branches load() a snapshot and later overwrite the whole file in a separate mutate { $0 = state }. Two overlapping hooks can clobber each other; e.g. concurrent spawn calls for different children can drop one record, which breaks dedupe and later cleanup.

Do the read/modify/write in a single store.mutate transaction and return any surface.close / surface.send_text work to run after the lock is released.

Also applies to: 12499-12503, 12527-12547, 12603-12611, 12632-12634

Verify each finding against the current code and only fix it if needed.

In `@CLI/cmux.swift` around lines 12477 - 12486, The code currently calls
store.load() then later calls store.mutate { $0 = state }, which allows race
conditions; change all those spots (the block using state, normalizedRoot,
rootSessionId, children, surfacesToClose and similar blocks at the other noted
ranges) to perform the read/modify/write inside a single store.mutate
transaction: inside mutate read the current state, compute and update
state.rootSessionId and state.children, collect and return a list of actions
(surface IDs to close or messages to send) from the mutate call, then run
surface.close / surface.send_text only after the mutate lock is released;
replace any separate store.load + later mutate pattern with this single atomic
mutate approach to avoid clobbering concurrent updates.

Create OMO state lock directory before acquiring flock

runOMO now points CMUX_OMO_STATE_PATH at ~/.cmuxterm/omo-state/bridge-...json, but withLockedState opens statePath + ".lock" before any parent-directory creation. On a clean install, ~/.cmuxterm/omo-state does not exist, so open(..., O_CREAT) fails with ENOENT and cmux omo exits before OpenCode starts. The directory creation in saveUnlocked is too late because execution never reaches it on first run.

Useful? React with 👍 / 👎.

Reuse fallback GhosttyKit cache after download failure

In scripts/setup.sh, reuse is gated on CURRENT_SOURCE == DESIRED_SOURCE; when pinned prebuilt download fails and fallback builds locally, metadata becomes local-build while DESIRED_SOURCE stays download. This makes every later setup.sh run retry download-prebuilt-ghosttykit.sh instead of reusing the known-good cache, which can add repeated multi-minute delays in offline/unreliable-network environments (the download script defaults to 30 retries with 20s delay).

Useful? React with 👍 / 👎.

P2: The cache-source equality gate causes repeated download retry loops after a fallback build, making setup slow/offline-unfriendly despite an existing valid cache.

Check if this issue is valid — if so, understand the root cause and fix it. At scripts/setup.sh, line 154:

<comment>The cache-source equality gate causes repeated download retry loops after a fallback build, making setup slow/offline-unfriendly despite an existing valid cache.</comment>

<file context>
@@ -41,41 +143,34 @@ while ! mkdir "$LOCK_DIR" 2>/dev/null; do
+CURRENT_SOURCE="$(cache_source)"
+CURRENT_LAYOUT="$(cache_layout)"
+
+if [ -d "$CACHE_XCFRAMEWORK" ] && [ "$CURRENT_LAYOUT" = "$CACHE_LAYOUT_VERSION" ] && [ "$CURRENT_SOURCE" = "$DESIRED_SOURCE" ]; then
+    echo "==> Reusing cached GhosttyKit.xcframework ($CURRENT_SOURCE)"
 else
</file context>

⚠️ Potential issue | 🟠 Major

Don't treat a dirty ghostty/ worktree as clean HEAD.

Both the download choice and the local seed path key off the commit SHA only. If ghostty/ has local edits, this can still pick the pinned prebuilt or reuse a .ghostty_sha artifact from an older working tree, so Ghostty changes get silently ignored. Force a source build for dirty worktrees and only reuse/write .ghostty_sha for clean trees.

Also applies to: 146-149

Verify each finding against the current code and only fix it if needed.

In `@scripts/setup.sh` around lines 110 - 130, The function
build_or_seed_local_ghosttykit currently keys reuse only on LOCAL_SHA_STAMP and
GHOSTTY_SHA and misses dirty worktree detection; update it to check the git
working tree inside the ghostty directory (e.g., git -C ghostty status
--porcelain or equivalent) and set an is_clean flag, then only treat the local
cache as valid when LOCAL_XCFRAMEWORK exists, "$local_sha" = "$GHOSTTY_SHA", and
is_clean is true; when the worktree is dirty force a source build (do not reuse
prebuilt) and only write/overwrite LOCAL_SHA_STAMP (printf '%s\n' "$GHOSTTY_SHA"
> "$LOCAL_SHA_STAMP") when the ghostty repo is clean; keep
install_cache_from_dir and the build steps but gate reuse/write of the
.ghostty_sha on the clean check (affecting build_or_seed_local_ghosttykit and
the same logic at the other mentioned block).