codex - 💡(How to fix) Fix Allow scheduled automations to run in an existing thread [1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openai/codex#22551Fetched 2026-05-14 03:34:34
View on GitHub
Comments
1
Participants
2
Timeline
4
Reactions
0
Timeline (top)
labeled ×2closed ×1commented ×1

Root Cause

Some recurring workflows are not just stateless prompts. They are operational routines that depend on the accumulated context of an existing thread:

  • prior decisions and corrections;
  • project-specific documentation already read and interpreted;
  • memory of fragile browser/tooling behavior;
  • user supervision history;
  • a prepared workspace;
  • authenticated browser flows;
  • recurring manual checkpoints.

When a scheduled automation always starts in a fresh thread, the run may technically have the same prompt, but it loses much of the practical context that made the workflow reliable in the first place.

RAW_BUFFERClick to expand / collapse

Feature request: allow scheduled automations to run in an existing thread

What feature would you like to see?

Please add support for scheduled automations that can target an existing Codex Desktop thread and append a new user turn to that same thread at the scheduled time, instead of always creating a new thread.

For example, from an active thread I would like to say:

Run this routine tomorrow at 10:00.

At 10:00, Codex should resume this same thread, append the scheduled instruction, and run the agent turn here.

Why this matters

Some recurring workflows are not just stateless prompts. They are operational routines that depend on the accumulated context of an existing thread:

  • prior decisions and corrections;
  • project-specific documentation already read and interpreted;
  • memory of fragile browser/tooling behavior;
  • user supervision history;
  • a prepared workspace;
  • authenticated browser flows;
  • recurring manual checkpoints.

When a scheduled automation always starts in a fresh thread, the run may technically have the same prompt, but it loses much of the practical context that made the workflow reliable in the first place.

Example use case

I have a recurring assisted operational routine that uses:

  • a local project workspace;
  • internal authenticated web systems;
  • a shared mailbox;
  • browser-based workflows;
  • local Markdown records and checklists.

When I run the routine manually in an existing thread, it works much better because the thread already contains the relevant operational context, previous corrections, and known environment pitfalls.

When the same routine runs as a scheduled automation in a new thread, it is more likely to fail or stop early because it has to reconstruct context and tool/browser state from scratch.

Expected behavior

Codex Desktop should allow an automation to be attached to an existing thread.

At the scheduled time, Codex should:

  1. open or resume the target thread;
  2. append the scheduled instruction as a new user turn;
  3. run the agent turn in that same thread;
  4. show the result in the same conversation history;
  5. handle overlaps safely if the thread is already running.

Suggested UX

Possible UI/API options:

  • “Schedule in this thread”;
  • “Run this prompt in this conversation at…”;
  • an automation field such as target_thread_id;
  • a visible indicator in the thread showing upcoming scheduled runs;
  • an option to cancel or edit the schedule from the thread.

Overlap behavior

If the target thread is already busy when the scheduled run fires, Codex could:

  • wait until the current turn finishes;
  • skip the run and leave a visible note in the thread;
  • ask the user before starting;
  • or queue the scheduled turn.

The important point is that it should not silently create a separate thread and lose the operational context.

Relationship to existing automation behavior

The current “new thread per automation run” model is useful for stateless tasks.

This request is for a complementary mode: thread-targeted automations for recurring, context-heavy, human-supervised workflows.

Acceptance criteria

A minimal implementation would allow:

  • selecting an existing thread as the automation target;
  • scheduling a future run against that thread;
  • appending the scheduled prompt to the same conversation;
  • showing success/failure in that same thread;
  • avoiding duplicate parallel runs if the thread is already active.

A stronger implementation would also preserve or restore relevant workspace/tool context where possible, especially for browser-based workflows.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

Codex Desktop should allow an automation to be attached to an existing thread.

At the scheduled time, Codex should:

  1. open or resume the target thread;
  2. append the scheduled instruction as a new user turn;
  3. run the agent turn in that same thread;
  4. show the result in the same conversation history;
  5. handle overlaps safely if the thread is already running.

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

codex - 💡(How to fix) Fix Allow scheduled automations to run in an existing thread [1 comments, 2 participants]