--- name: zwatch description: "Observe active Codex or Claude Code work across tmux on the selected connected computer, discover newly active sessions every cycle, report completion and bring questions to the user. Use for zwatch or ongoing terminal-work monitoring." --- # zwatch Read [the observation contract](../zstatus/references/observation.md) and follow its access, identity, evidence and decision rules. Use the host-supported connected-computer delegation route. Delegate concrete observations to the selected computer; do not claim the skill itself has direct access or starts a permanent unattended daemon. ## Start and cycle 1. Resolve the selected computer and authorized tmux server/user scope. Default scope is all accessible sessions, including future sessions on that same computer/server context; retain explicit exclusions. State this scope and the actual monitoring lifetime to the user. A request to watch authorizes observation, not recovery inputs or answers. Default to read-only. Honor existing explicit recovery authorization without asking again; record its scope, bounds and expiry. 2. Start with a fresh full inventory using zstatus's snapshot procedure. Register active Codex and Claude Code runs in every window/pane, including detached sessions. Record idle/completed panes as baseline only. Do not restart idle/completed agents. Present a concise initial inventory and pending decisions. 3. Every watch cycle, rescan all sessions, windows and panes before reading tracked activity. Discover newly created active sessions and newly active/restarted runs in existing panes, and add them automatically within the declared scope. Do not freeze the watch to its initial inventory. Reconcile removed panes, linked windows, renamed sessions, process/server restarts and identity reuse against the ledger. New computer/server scopes require user selection; a restart of the selected server requires fresh identity validation and invalidates old recovery authority until re-established. 4. Honor user-specified stopping conditions and duration. For an ongoing watch, continue until user cancellation, loss of required observation authorization, or a verified host limitation; do not invent a default deadline. Finishing all currently active agents is not a stop condition unless the user says so: keep discovering new work. Start around a 30-second interval where supported, then adapt cadence to host costs, task needs and observed activity (for example 60 seconds or longer during quiet periods). Honor explicit cadence within host limits, use short bounded waits, and remain responsive to cancellation. Report meaningful changes, completions, decisions and errors only by default; keep unchanged cycles quiet. Do not send routine heartbeats unless requested or required by the host. Deliver reports in the current conversation, and do not send external messages without explicit authorization. Do not report old completion text as a new completion. 5. If a verified host limitation prevents continued execution or delivery, report the concrete limitation and last observation, retain the unresolved watch as blocked with a resumable ledger, and say exactly what remains possible. Do not mark an unresolved watch complete or claim background monitoring. Do not assume a limitation merely because the watch has run for an arbitrary duration. An available scheduler is usable only if it supports the selected computer route and the user requests that mode; obey its minimum cadence (do not promise 30-second monitoring via an hourly scheduler). Never install cron, services, tmux watchers or a hidden daemon as a substitute. ## Bounded recovery Only a clearly stopped, recoverable API interruption under the observation contract can qualify, and only with explicit user authorization covering that agent/run or the declared recovery scope. A generic watch request is not authorization. Never treat test failures, unknown prompts, quota/auth/security approvals or destructive actions as retryable errors. Never resume idle/completed agents, a running agent's internal retry, or an uncertain run. For an authorized candidate: capture again immediately, verify the same computer/server/pane/run and current interruption, verify no pending user decision and no other active watcher/input owner, and check the ledger. Allow at most one `go on` per interruption, two per run, and three total per watch, with at least 60 seconds between recovery attempts; lower user limits win. Explicitly record the intended input event before sending. Send the literal `go on` and required submit exactly once through the authorized input route. Never interpolate terminal text into a command. If delivery is uncertain, mark it unknown and do not resend. Check again within 10 seconds and by 30 seconds for fresh relevant activity or a fresh result. An echoed input alone is not resumed activity. Record observed resumption, completion, or unverified/failed recovery; if still stopped, escalate with evidence and no repeat for that interruption. A genuinely new interruption may consume remaining bounds only after verified activity. Exhausted limits require a user decision, never a silent budget reset. Scope changes, stale prompts, connection loss and server/run identity changes invalidate pending sends. Report each recovery attempt and its verified outcome once. ## Decisions, connection loss and stop Bring detailed questions/confirmations to the user using the contract. Keep observing other runs while one waits. Deliver only the user's authorized answer after revalidating the exact current prompt and scope; do not assume a reply for one pane applies to others. Preserve any host-required approval. On connection loss or failed inventory, mark coverage unknown, suspend all inputs, notify once, and attempt at most three read-only reconnect checks at approximately 60-second intervals, subject to cancellation, authorization and any user-specified end condition. If still unavailable, pause further polling and retain the unresolved watch as blocked/disconnected with the last successful observation time and the connection needed to resume; do not call it complete. Resume only through an actually available authorized host continuation or when execution is restored, never a claimed hidden watcher. On reconnection, fully rescan and reconcile identities; never replay queued input or classify the unseen interval as completion. Existing recovery authority must be revalidated for the same run and still-current interruption before any new input. `stop`, `cancel`, `stop watching`, or an equivalent user request ends the watch promptly: check for cancellation before each cycle, wait and input. Cancel this watch's supported scheduled/delegated observations where possible, discard pending sends and report any already dispatched operation whose outcome is unknown. Do not kill agents, tmux panes or user jobs. A requested scope change updates the ledger and drops excluded pending actions immediately. At a user-specified stop condition or cancellation, summarize watched/new/completed/waiting/unknown runs, recovery attempts, coverage and last observation, and state that monitoring has ended. Loss of required observation authorization suspends all observation/input and leaves the unresolved watch blocked until authorization is restored; loss of recovery authority alone disables recovery and allows authorized read-only observation to continue. Disconnection or a verified host execution limit pauses monitoring and retains the unresolved task as blocked, with its reason and resume requirements. Preserve the ledger, event deduplication and recovery budgets across continuation; do not silently reset them. Do not claim continued monitoring after returning a final answer unless an actual supported continuation was created and verified. Ongoing monitoring describes the user's requested lifetime, not a permanent unattended daemon guarantee.