[BUG] TUI: Visual glitch when background stages run on Windows [Claude Code, Opencode, Github Copilot] [Dev]

[flora131]

Summary

Some kind of UI rendering glitch shows up on Windows when one or more
background (headless) stages are running. The exact symptom hasn't been
captured yet — filing this as a tracking issue so we don't lose it;
need more repro detail from @lavaman131 before we can root-cause.

The relevant surface is the orchestrator window's status line, which
renders the background-stage counter through a tmux/psmux user-option
indirection (#{@atomic-bg-tasks}) that is pushed by
packages/atomic-sdk/src/components/orchestrator-panel.tsx:183
(pushBackgroundTasksIndicator) and consumed by the format string
compiled in
packages/atomic-sdk/src/tui/attached-statusline.tsx:50
(BACKGROUND_TASKS_OPTION / backgroundTasksValue). The same file
already documents two psmux 3.3.3 quirks the current renderer works
around (nested #{?…} leaking fragments across branches; commas inside
#[…] style attributes), so a Windows-only glitch in this area is
plausible.

Affected agents

Likely provider-agnostic — background-stage rendering is driven by the
runtime/TUI layer, not by any specific agent SDK. To be confirmed once
we have repro.

• Claude Code
• GitHub Copilot CLI
• OpenCode

Affected platforms

• Linux
• macOS
• Windows

Reproduction

TODO (@lavaman131): capture exact steps. The natural-language
report we have is "weird UI glitch in Windows for background stages"
with no screenshot or specific symptom yet.

Working hypothesis for what to capture when reproducing:

1. Run atomic --version and the psmux version (psmux -V) on the
   Windows host.
2. Start a workflow with at least one headless / background stage, e.g.
   atomic workflow -n <workflow-with-bg-stage> -a <agent> — anything
   that calls orchestrator.backgroundTaskStarted() /
   backgroundTaskFinished().
3. Attach to the orchestrator window so the status-line bg-tasks
   indicator is visible.
4. Note the exact glitch — screenshot or terminal recording — and the
   stage transition (start vs. finish vs. count change) that triggers
   it.

Expected vs Actual

• Expected: the orchestrator status line renders the
  ◆ <N> background segment cleanly while background stages run and
  collapses to empty when the count returns to zero, with parity to
  Linux/macOS.
• Actual: unknown — visible UI glitch on Windows; details pending.

Hypothesis / Suspected location

Pending repro, the most plausible suspects are:

• packages/atomic-sdk/src/tui/attached-statusline.tsx:58
  (backgroundTasksValue) — pre-styled tmux markup; psmux 3.3.3 has
  known render-parser sensitivities around #[…] and #{?…}.
• packages/atomic-sdk/src/tui/attached-statusline.tsx:142
  (whenOrchestrator("#{@atomic-${BACKGROUND_TASKS_OPTION}}", "")) —
  the user-option indirection used to keep the conditional flat.
• packages/atomic-sdk/src/runtime/tmux.ts:218 notes that run-shell
  inheritance is incomplete on Windows psmux, which has bitten this
  surface before; the bg-tasks push goes through set-option, but
  worth double-checking that the option write actually lands in the
  Windows psmux server.
• packages/atomic-sdk/src/components/orchestrator-panel.tsx:183
  (pushBackgroundTasksIndicator) — the writer side; verify the
  session-scoped target arg resolves on Windows.

Test Plan

• Once repro is captured: add a regression that exercises the
  bg-tasks status-line render path on the Windows-x64 CI matrix entry
  in .github/workflows, asserting the rendered status line matches
  the macOS / Linux baseline for a workflow with N background stages
  active.
• If the glitch is in the format-string compiler, extend the existing
  unit coverage around backgroundTasksValue /
  attached-statusline.tsx rather than only fixing it inline.