Feature: Claude Code-style monitor tool with first-class remote-host support #44855

Activity

1. github-actions

   added

   enhancementNew feature or requestNew feature or request

   remote

   on Sep 11, 2026
2. ysyysy115 commented on Sep 17, 2026

   

   ysyysy115

   on Sep 17, 2026

   More actions

   Very important and useful feature!
3. abcjhby2871 commented on Sep 24, 2026

   

   abcjhby2871

   on Sep 24, 2026 – with ChatGPT Codex Connector

   Author

   More actions

   Update (2026-09-24): this is becoming a core primitive for long-horizon / research-agent workflows

   I want to sharpen the motivation for this request.

   This is no longer just about “Claude Code Monitor parity”. A first-class remote event-driven wait/wake primitive is increasingly a prerequisite for long-horizon autonomous engineering, ML research, and RSI-style experiment loops.

   The desired execution model is:

   model reasons
       ↓
   launch deterministic / expensive work
       ↓
   model goes fully dormant
       ↓
   remote job / watcher owns the wait
       ↓
   meaningful event occurs
       ↓
   same visible Codex thread wakes
       ↓
   model reasons again
   

   rather than:

   model → poll → model → poll → model → poll → ...
   

   Evidence from Codex itself

   Several recent issues now appear to converge on the same missing runtime substrate:

   • Feature: an agent-callable monitor tool that wakes Codex on background events (logs, files, builds, CI) without polling #29922 — agent-callable monitor with idle wake.
   • Codex CLI: add persistent self-healing monitor workflows for long-running jobs #32993 — persistent self-healing monitor workflows for long-running jobs.
   • Feature request: Event-driven wake-up when a local process completes #46085 — event-driven wake-up when a process completes.
   • Feature request: external wake / message injection for an existing Codex Desktop or CLI session #47193 — the missing bridge from an external event into the existing visible Desktop/CLI session.
   • Codex CLI repeatedly wakes xhigh to poll deterministic long-running jobs, exhausting finite weekly usage before task completion #45974 — a particularly concrete failure mode: a high-reasoning model repeatedly polling deterministic long-running jobs, with thousands of tool interactions / hundreds of waits, eventually exhausting the user's finite usage before the actual machine work completed.

   That last case is important because it shows this is not only a UX improvement. It is also an inference-efficiency / cost architecture issue: machine progress should not require model inference.

   Why remote execution should be first-class

   For ML, robotics, simulation, scientific computing, and increasingly AI-research-agent workloads, the expensive work is normally not running on the laptop:

   Codex Desktop
         │
         └── remote GPU / Docker / Slurm
                   │
                   ├── train
                   ├── checkpoint
                   ├── eval
                   └── logs / metrics
   

   These jobs can run for hours or days. A useful agent runtime therefore needs to let the watcher live with the remote execution context, survive an idle UI, and resume reasoning only at decision points such as:

   • process exit / failure;
   • OOM / NaN / traceback;
   • checkpoint ready;
   • evaluation complete;
   • metric regression / plateau;
   • Slurm state transition;
   • a user-defined log/file/event condition.

   A local-only watcher tied to the Desktop process would solve only a small subset of this problem.

   The competitive bar is also moving

   Meta's Muse Code now documents several runtime concepts that make this direction especially relevant:

   • persistent asynchronous background agents;
   • goals / long-running loops;
   • background tasks with status/control;
   • workflows that continue in the background and deliver completion back into the conversation without user polling;
   • session messaging and a durable event log.

   References:

   • https://dev.meta.ai/docs/muse-code/interactive
   • https://dev.meta.ai/docs/muse-code/workflows
   • https://dev.meta.ai/docs/muse-code/extending
   • https://research.meta.ai/blog/introducing-muse-code-and-muse-spark-1-2

   I do not think Codex needs to copy Muse's architecture. But it does mean that “the model can reason for a long time” is no longer sufficient; the runtime has to remain alive cheaply and reactively around long-running external work.

   Why this matters for research / RSI-style loops

   Recent research is also making this workflow concrete rather than hypothetical. For example, AIDE² reports an autonomous 8-day recursive self-improvement run in which an AI research agent repeatedly modifies itself, benchmarks the modified agent, and keeps successful changes:

   https://arxiv.org/abs/2609.26457

   Regardless of whether we call a particular workflow “RSI”, the systems pattern is the same:

   hypothesis / code change
           ↓
   long training or benchmark
           ↓
   evaluation artifact
           ↓
   decision
           ↓
   next experiment
   

   The model should be active at the decision boundaries, not continuously burning inference while the GPU/cluster is doing deterministic work.

   Suggested acceptance criteria

   I would treat #29922 (monitor), #47193 (live-session wake), and this issue (remote semantics) as pieces of one substrate.

   A strong implementation would ideally provide:

   1. Remote binding — a monitor launched from a remote Codex workspace runs on that same host/container/workspace.
   2. True dormancy — while the watcher is quiet, there are no model calls / reasoning turns.
   3. Same-thread wake — an event resumes the same visible Desktop/CLI thread and, if applicable, its active Goal.
   4. Safe delivery — if the model is already in a turn, events are queued/coalesced rather than interrupting or spawning duplicate reasoning.
   5. Reconnect semantics — temporary Desktop disconnects / SSH drops should not silently lose watcher state; persistence would be ideal, but at minimum loss should be explicit and recoverable.
   6. Structured event metadata — monitor id, host/workspace, timestamp, source, exit status / matched condition, and bounded output.
   7. Control surface — list / pause / resume / stop monitors, with an obvious local-vs-remote indicator.
   8. Common sources — process completion, stdout/stderr/log matching, file changes, and arbitrary shell-based watchers so Slurm/Docker/training systems do not need bespoke integrations.
   9. Autonomy guardrails — retry/action budgets and bounded self-repair loops, so event-driven automation cannot silently turn into an unbounded repair cycle.

   An optional higher-level layer could support semantic events such as:

   CHECKPOINT_READY
   EVAL_COMPLETE
   METRIC_PLATEAU
   OOM
   NAN
   JOB_FAILED
   TRAIN_COMPLETE
   

   but the core shell/process monitor + durable wake primitive would already make those easy to build.

   Example research loop

   Codex Goal: improve validation success rate
           ↓
   edit code/config
           ↓
   submit training on remote GPU
           ↓
   monitor goes quiet; Codex sleeps
           ↓
   EVAL_COMPLETE {score: 0.78}
           ↓
   Codex wakes, inspects artifacts, decides next experiment
           ↓
   submit next run
           ↓
   sleep again
   

   To me, this is the important distinction:

   Long-horizon autonomy should mean a persistent runtime with sparse, event-triggered reasoning — not continuous model polling.

   With Remote SSH now a major Codex workflow, making this primitive remote-aware from the beginning would be disproportionately useful for research and engineering users.
4. abcjhby2871 commented on Sep 24, 2026

   

   abcjhby2871

   on Sep 24, 2026 – with ChatGPT Codex Connector

   Author

   More actions

   Additional UX / lifecycle requirement: a unified Monitor Manager

   One more product-level requirement seems important if monitors become persistent and remote-aware: there should be a single place to inspect and manage every active monitor.

   Without this, persistent monitors can easily become invisible background state. That creates two problems:

   1. Resource leaks / forgotten watchers — a remote watcher may keep running after the user has mentally moved on from the task.
   2. Unexpected future wakeups / usage — an old monitor may fire hours or days later and trigger model work the user no longer wants.

   A useful Monitor Manager could show, at minimum:

   • monitor name / description;
   • status: active / paused / fired / stopped / disconnected;
   • source: process / log / file / shell watcher / scheduler;
   • execution target: local / remote host / container / workspace;
   • owning thread / Goal;
   • created time and last event time;
   • trigger condition;
   • whether the watcher itself is consuming compute/resources;
   • wake policy;
   • expiration / TTL, if configured.

   And provide bulk controls such as:

   • pause / resume;
   • stop;
   • stop all monitors for a thread / workspace / host;
   • change expiration / TTL;
   • rebind a monitor to another thread;
   • inspect recent events / wake history.

   A small persistent badge/count in Desktop would also help surface "you still have N active monitors", especially before quitting the app or disconnecting from a remote machine.

   Wake destination should be configurable: original thread vs new thread

   I also think monitor delivery should explicitly support both modes:

   1. Wake the original thread

   Best for a tightly coupled long-running workflow:

   thread A
     ↓
   launch training
     ↓
   monitor
     ↓
   event
     ↓
   resume thread A with full context
   

   This is ideal when the event is clearly part of the same Goal / experiment.

   2. Spawn a new thread from the event

   Best when the original thread should remain clean, is already busy, or when the event should be handled independently:

   thread A launches monitor
             ↓
          event fires
             ↓
      create thread B
             ↓
   B receives:
   - monitor metadata
   - triggering event
   - bounded relevant context
   - link/reference back to thread A
   

   This could be especially useful for:

   • multiple concurrent experiments;
   • long-running training across several remote hosts;
   • CI / regression watchers;
   • independent failures that should not interrupt the main reasoning thread;
   • delegating event handling to a cheaper/faster model or subagent.

   A simple policy might be something like:

   wake_target = original_thread | new_thread
   

   with an optional "ask on fire" / routing rule later.

   For long-horizon agent systems, this makes monitors feel less like hidden shell processes and more like first-class persistent objects with ownership, lifecycle, routing, and visibility.

   I would consider the unified management surface and explicit wake routing part of the acceptance criteria, not just nice-to-have UI polish.
5. sarinstein-yan commented on Oct 18, 2026

   

   sarinstein-yan

   on Oct 18, 2026

   More actions

   +1, especially for research workflows combining remote HPC jobs and queued quantum-hardware experiments. Deterministic watchers should run near the jobs and wake the original Codex thread only on completion or failure. Remote reconnect handling and zero model calls while nothing changes would make this much more useful than periodic AI checks.