Keep OpenCode sessions alive during theme changes

[bjarneo]

Why

Omarchy sends SIGUSR2 to every running OpenCode process after a theme change. OpenCode uses this signal to reload its configuration. The reload disposes active instances, which can stop model requests and tool calls.

What changed

• Stop calling omarchy-restart-opencode during theme changes.
• Add omarchy-theme-set-opencode.
• Send the current Omarchy terminal colors to each running OpenCode TTY.
• Send the terminal theme query that lets OpenCode refresh its system theme without reloading its worker.
• Keep omarchy-restart-opencode available for manual configuration reloads.

Existing Alacritty, Kitty, Ghostty, Foot, and tmux theme paths remain unchanged.

Tests

• ./test/cli
• bash -n bin/omarchy-theme-set bin/omarchy-theme-set-opencode bin/omarchy-theme-osc bin/omarchy-theme-set-foot

[Copilot]

Copilot wasn't able to review any files in this pull request.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[bjarneo]

Been running locally since this PR was made. Works well.

[omarchybot]

Reviewed. The approach holds up and the mechanism does what the description claims — two small fixes pushed to the branch, one thing left that is your call.

What was checked. Read the diff and the surrounding theme-set path, ran ./test/cli on a disposable VM (passes, exit 0), and exercised omarchy-theme-set-opencode against a real pts with two stand-in processes named opencode sharing one tty. It emits exactly one burst per tty — 302 bytes, OSC 10/11/12/17/19, sixteen OSC 4, then CSI ?996n — so seen_ttys deduplicates correctly and the trailing query lands once. No opencode binary was run; opencode's own behaviour was checked against its source rather than executed.

The refresh mechanism. OpenCode's system theme renders through ANSI 0-15 with none for fg/bg, so the OSC burst retints a running session straight from the terminal, and the TUI's handleThemeNotification in packages/tui/src/context/theme.tsx at v1.18.21 matches \x1b[?997;1n / \x1b[?997;2n and calls refreshSystemTheme(). That refresh compares a palette signature rather than the light/dark mode, so a dark-to-dark theme switch re-derives the generated gray scale too — the query is not just a light/dark flip. Since config/opencode/opencode.json ships "theme": "system", this covers the shipped configuration.

Mid-request sessions. No signal is sent at all now, so nothing disposes an instance mid-generation. The concurrent write from omarchy-theme-set-opencode and omarchy-theme-set-tmux — both can hit the same pane pts under run_parallel — is a single ~300-byte printf each, and the kernel serialises tty writes, so they arrive as two whole bundles rather than interleaved bytes.

Leaked sessions. None. seen_ttys is process-local, readlink returns a pathname rather than holding an fd, and the redirect opens and closes the pts for one write. A process that exits before readlink is skipped.

Pushed to the branch:

• 13bb62f3 — omarchy-restart-opencode's summary still read "(used by the Omarchy theme switching)", which omarchy restart prints verbatim; nothing in the tree calls it from theme switching after this PR. Dropped the clause so the listing matches what you say in the description, that the command stays for manual reloads.
• 44845942 — printf ... >"$tty" 2>/dev/null applies redirections left to right, so a failed open on a pts that vanished between readlink and the write prints a bash error to the caller's stderr before the discard takes effect. Verified both orderings against a nonexistent pts: the current one prints, 2>/dev/null >"$tty" is silent. || true was already swallowing the status; this makes the guard cover the open as well.

Still open, low, and yours to decide. The CSI ?996n reply is terminal input, so it goes to whatever owns that pts's foreground process group, not to the process that prompted it. A suspended TUI is the obvious case, but the likelier one is opencode run — headless, matched by pgrep -x opencode, foreground on its tty, and not reading the sequence — where the reply sits in the input buffer and surfaces as junk at the shell prompt afterwards. Cosmetic next to the SIGUSR2 kill it replaces, and there is no clean way from outside to tell a TUI apart from opencode run, so no guess was pushed for it.

Related. #8004, #8264 and #8684 all cover this ground, and #8264 and #8684 add a file at the same path, bin/omarchy-theme-set-opencode. #8684 goes the other way — it renders an OpenCode theme file and migrates users off "theme": "system" onto a shipped "omarchy" theme — where this PR keeps the shipped system setting working. Issues #8002 and #8389 describe the bug this fixes. Which approach lands is the maintainer's call, and nothing was changed on those.

Reviewed by Claude Opus 5 in Claude Code with a second opinion from Codex at xhigh reasoning. Codex agreed on the stale summary, which had already been written down here, so that agreement is worth less than it looks — its read scope is not currently confined, so its independence is not guaranteed. The redirection-ordering defect is its own find, and it is credited on that commit.