Oracle flagged: staleSweepCompleted was set to true BEFORE
sweepStaleOmoAgentSessions() ran, so any throw from the first
invocation would permanently disable stale cleanup for the rest
of the process lifetime.
Fix:
- Move staleSweepCompleted=true into the try-block success branch.
- Add staleSweepInProgress guard so concurrent onSessionCreated calls
do not invoke sweep twice in parallel (sweep is idempotent, but the
guard prevents doubled log noise).
- finally{} clears the inProgress flag regardless of outcome.
- cleanup() resets both flags.
Two new tests cover: retry after a thrown first attempt, and single
invocation when subsequent spawns follow a successful first sweep.
Oracle flagged a regression introduced in PR #3507 commit 21554be8:
event.ts routed session.error through tmux pane cleanup BEFORE the
existing session-recovery / model-fallback logic ran.
Problem: when session.error was recoverable (context window limit,
quota rate limit, provider fallback), the recovery/fallback code would
successfully continue the SAME session - but by then its tmux pane had
already been destroyed. User-visible symptom is exactly the original
complaint - 'screen appears but streaming stops working' after an
auto-retry.
Fix is the minimal revert: remove the onSessionError funnel from
event.ts and drop onSessionError from the manager. Fatal errors that
actually end a session still fire session.deleted, which continues to
trigger cleanup correctly. Non-fatal error streams stay attached to
the surviving pane.
Follow-up to PR #3507 addressing the Oracle-noted operational limitation:
per-PID isolated session names (getIsolatedSessionName(process.pid)) mean
that when an opencode process is SIGKILL'd (or the machine hard-reboots),
the old omo-agents-<old-pid> tmux session survives forever because nothing
is around to kill it.
Added sweepStaleOmoAgentSessions() that:
1. Lists tmux sessions matching /^omo-agents-(\d+)$/
2. For each, checks process.kill(pid, 0) to detect a dead PID
3. Skips our own PID
4. Calls killTmuxSessionIfExists for every session whose owner process is gone
Wired into TmuxSessionManager.onSessionCreated() as a one-shot (guarded by
staleSweepCompleted flag) so it runs lazily on the first subagent spawn when
isolation="session". The flag is reset in cleanup() so subsequent process
restarts re-run the sweep.
6 new tests cover: outside-tmux no-op, no matching sessions, multiple dead
PIDs, current PID skip, live PID skip, list-sessions failure.
Manual E2E verified on real tmux:
- Created omo-agents-99999, sweep killed it
- Spawned our own omo-agents-<pid>, closeTmuxPane returned true even after
pane auto-destroy from Ctrl+C
- Final tmux list-sessions shows zero omo-agents-* orphans
Oracle flagged the previous commit: "omo-agents" was a shared constant,
so when two plugin instances ran in the same tmux server they wrote into
the same session. One instance's cleanup would then kill-session on the
shared name and tear down the other instance's live attached panes.
Replace the const ISOLATED_SESSION_NAME with getIsolatedSessionName(pid)
which defaults to process.pid, so every opencode process owns its own
"omo-agents-<pid>" session. spawnTmuxSession and cleanup both resolve
the name through this helper. Discovery is straightforward from the
host tmux via 'tmux list-sessions | grep omo-agents-'.
Manager test covers two concurrent managers and asserts each kills a
per-pid session name, proving they no longer collide on a global name.
Three defects observed with tmux.isolation="session" where the omo-agents
session was left with orphan fish panes after subagents finished:
1. cleanup() never ran 'tmux kill-session -t omo-agents'. If any pane
lingered (for example because opencode attach stayed blocked on SSE),
the isolated session survived process shutdown. Now we explicitly kill
the shared session through killTmuxSessionIfExists when isolation is
"session".
2. session.error events bypassed tmux cleanup entirely. Only session.deleted
closed panes, so any provider error that did not escalate into a delete
left the pane behind. Added onSessionError on TmuxSessionManager, wired
from plugin/event.ts, which funnels through the same onSessionDeleted
close path for tracked sessions only.
3. retryPendingCloses() only ran when a new session was created. If the
main process went idle after a failed close, the pending session stayed
pending forever. TmuxPollingManager now accepts the retry callback and
fires it on every tick, alongside the existing stability-based close
sweep.
Manager tests cover isolation=session kill invocation, inline/window
isolation skipping the kill, the onSessionError happy + untracked paths,
and an isolated-session kill failure that must not break cleanup.
waitForSessionReady polled session.status for up to 10s before the pane was registered, but session.status only becomes visible after promptAsync starts. Blocking pane tracking on that signal caused the attach client to see an empty session and render a blank TUI.
Track the pane immediately after spawn, and run the readiness probe in the background purely for observability.
Ultraworked with [Sisyphus](https://github.com/code-yeongyu/oh-my-openagent)
Co-authored-by: Sisyphus <clio-agent@sisyphuslabs.ai>
- Add afterAll(() => { mock.restore() }) to 52 test files missing cleanup
- Rewrite create-tool-guard-hooks.test.ts to use spyOn instead of barrel mock
- Fix skill-mcp-manager OAuth tests with missing mockTokens/mockLogin definitions
- Fix start-work hook: show worktree active block on resume with existing worktree_path
- Extract createWorktreeActiveBlock to worktree-block.ts to avoid circular import
- Replace 80-line isolated test runner CI config with single `bun test` command
- runtime-fallback: guard session.error with sessionRetryInFlight to prevent
double-advance during active retry; expand session.stop abort to include
sessionAwaitingFallbackResult; remove premature pendingFallbackModel clearing
from auto-retry finally block
- hashline-edit: add HASHLINE_LEGACY_REF_PATTERN for backward-compatible
LINE:HEX dual-parse in parseLineRef and normalizeLineRef
- tmux-subagent: defer session on null queryWindowState; unconditionally
re-queue deferred session on spawn failure (not just close+spawn)
- ultrawork-db: wrap new Database(dbPath) in try/catch to handle corrupted DB
- event: add try/catch guards around model-fallback logic in message.updated,
session.status, and session.error handlers
* fix(tmux): send Ctrl+C before kill-pane and respawn-pane to prevent orphaned processes
* fix(tmux-subagent): prevent premature pane closure with stability detection
Implements stability detection pattern from background-agent to prevent
tmux panes from closing while agents are still working (issue #1330).
Problem: Session status 'idle' doesn't mean 'finished' - agent may still
be thinking/reasoning. Previous code closed panes immediately on idle.
Solution:
- Require MIN_STABILITY_TIME_MS (10s) before stability detection activates
- Track message count changes to detect ongoing activity
- Require STABLE_POLLS_REQUIRED (3) consecutive polls with same message count
- Double-check session status before closing
Changes:
- types.ts: Add lastMessageCount and stableIdlePolls to TrackedSession
- manager.ts: Implement stability detection in pollSessions()
- manager.test.ts: Add 4 tests for stability detection behavior
* test(tmux-subagent): improve stability detection tests to properly verify age gate
- First test now sets session age >10s and verifies 3 polls don't close
- Last test now does 5 polls to prove age gate prevents closure
- Added comments explaining what each poll does
- Account for tmux pane dividers (1 char) in all size calculations
- Reduce MIN_PANE_WIDTH from 53 to 52 to fit 2 columns in standard terminals
- Fix enforceMainPaneWidth to use (windowWidth - divider) / 2
- Add virtual mainPane handling for close-spawn eviction loop
- Add comprehensive decision-engine tests (23 test cases)
YeonGyu-Kim