Native async wake/sleep mechanism for long-running agent loops

Open 💬 4 comments Opened Jul 10, 2026 by onetensor

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What variant of Codex are you using?

CLI

What feature would you like to see?

Problem

When running autonomous autoresearch type loops, such as overnight ML experiments, multi-hour training runs, iterative research pipeline, the agent has no way to yield its turn while waiting on a long job. The current workaround is polling:

sleep 300; tail -n 80 experiment.log

Repeated dozens of times across a single training session, this fills the transcript with status checks that contribute nothing to reasoning (which is also very annoying to read through). Over a multipler hour or day run, this is the difference between a coherent research loop and one that falls apart because the context window is full of garbage. The alternative is that the agent just ends its turn, but this currently means that it will not start back up on its own after the run completes, which diminishes the length of time it can work for

Proposed behavior

The agent should be able to kick off a long-running command, end its turn (if it wants), and automatically resume with a new turn when the job finishes, not just receive a notification, but actually start working again with the completion context. N polling turns collapse to at most 1 completion turn. The agent's context budget is spent on the work, not the waiting.

Optionally, progress wakes at configurable checkpoints (e.g. every 2 hours, or at specific elapsed times) would let the agent check in at a small number of predetermined points rather than continuously.

Prior art

I built [AgentWake](https://github.com/onetensor/agentwake) to solve this for my own Codex autoresearch workflows. It uses tmux pane injection as the push channel, the agent submits a job via agentwake run, the job runs in a background tmux session, and when the job finishes, a minimal completion message is pasted into the agent's pane and submitted as input, so the agent actually wakes up and begins its next turn automatically (if the pane is idle). It includes idle aware delivery, progress wakes, and log preservation.

I've been using this daily with Codex agents for autonomous research loops, and it works well as a third party tool. However, a native implementation would be nice, it could hook into Codex's sandbox model, session management, and approval flow directly rather than going through tmux.

Recently, while using Claude Code, I saw that it had also shipped a native mechanism that addresses this same problem, where Claude can start background tasks and end its turn, then be woken when they complete without burning context on polling. The fact that this pattern emerged independently in both tools suggests it's a fairly fundamental need for agentic CLI workflows, not a niche preference.

Implementation note

AgentWake uses tmux because it was the most practical third-party approach for me to implement, there's no other reliable way to inject a future prompt into a running TUI from the outside. A native Codex implementation wouldn't need that. It could use internal TUI event hooks or the app-server directly, which would be cleaner and eliminate the tmux dependency entirely, I am just including my personal implementation because it may be useful.

Additional information

_No response_

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 1 month ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

#32188

Powered by Codex Action

onetensor · 1 month ago

Reviewed previous issues, and I agree that it covers the same core idea of waking an idle Codex session when a background command completes, however, I am keeping this up due to some behavioural extensions/differences that could be useful.

I wanted to note a few additional behaviors from AgentWake that I believe are beneficial and may still be useful when designing a native implementation:

Scheduled progress wakes: optional one-shot or recurring checkpoints while a job is still running, such as waking after 2 hours or every 4 hours, rather than only on final completion.
Durable completion state: the job result and logs are preserved independently of whether the wake can be delivered immediately, so a completion is not silently lost if the session is busy or unavailable.
Idle-aware delivery policies: wake immediately, wake only if currently idle, wait until idle, or record the notification for manual delivery.
Bounded, customizable notifications: completion messages are minimal by default, with an optional capped log tail, while the full output remains available separately (since being woken to check the sanity of a run, and then having to use another turn just to run a command to poll the tail of a log, when that was almost definitely the intent for any midrun wakes already, seems like it would be worth merging into the message the agent recieves).
Multiple-job handling: completion notifications remain individually identifiable and can be coalesced or deferred without requiring polling turns.

I have been using these behaviors in real long-running Codex/autoresearch workflows, and the main practical lesson has been that recording job completion and waking the model should be treated as separate steps: completion should be durable, while delivery can safely wait for an appropriate moment.

I am happy for this issue to be treated as an extension or design note related to #32188 rather than as a competing proposal. I mainly wanted to document the extra behaviors in case any of them are useful for the native design.

JinnanWeng-coder · 1 month ago

I have the same requirement for long-running local research and ML experiments.

My typical workflow is:

Codex starts a training or simulation process that may run for several hours.
The current agent turn should finish and become idle.
The process should continue locally without model polling or repeated status-check turns.
When the process exits, Codex should receive a bounded completion event and automatically start exactly one continuation turn.
The continuation turn should read the generated logs and result files, analyze the experiment, and optionally launch the next experiment.

Goal mode does not fully solve this use case because it may continue producing turns while the experiment is still running. A foreground command keeps the current turn open, while ending the turn currently requires the user or an external watcher to manually resume the session.

The ideal behavior would be an opt-in mechanism such as on_exit: "wake" or an awaitable background-task handle, with these properties:

no model inference while waiting;
exactly one wake-up when the process exits;
exit code, duration, and bounded output included in the completion context;
no duplicate wake-up if the result was already observed manually;
support for reconnecting to the session;
compatibility with CLI, IDE, and Codex App local tasks.

This would be particularly useful for overnight training, SDR experiments, simulations, long test suites, builds, and deployment jobs.

IgorGanapolsky · 7 days ago

Durable completion vs delivery is the right split. Polling sleep 300; tail fills the window; native on_exit: wake with exactly one continuation turn (exit code, duration, bounded log) is the CLI fix. Treat completion as durable even if the pane is busy, then deliver when idle.

That still lives in a local session. AgentWake/tmux die when the laptop sleeps. If the overnight training loop has to outlive the lid, it needs a host that does not sleep. I run that as hosted Hermes on a fenced VPS, $10/mo, 14-day trial: https://thumbgate.app — money/customer/prod pauses in the browser.