›_ Codex Issues
Codex Issues / #24415

Run parallel side sessions with agent-like inspectability

Open 💬 2 comments Opened May 25, 2026 by tmsdnl
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What variant of Codex are you using?

APP, IDE, CLI

What feature would you like to see?

It would be useful to have a cleaner way to run noisy side workflows without filling the main thread.

Examples are: commit, review, test triage, CI/log inspection, release notes, etc. These workflows often need the main thread’s context to start, but then they call a bunch of tools and generate intermediate state that I don’t want added back to the main conversation.

Or even something longer-running: run the app, watch logs/browser output, and report only relevant errors or regressions back to the main thread.

Codex already has pieces that almost work:

  • /side has the right isolation mechanics, and skills already package reusable workflows. I use them together with custom skills like $commit and $review, but in the CLI /side is a detour I have to back out of, and the result handoff is manual.
  • Subagents have the right mechanics: they can run in parallel and I can inspect what an individual agent is doing, then return to the main thread. But invoking them still adds orchestration chatter to the main thread, and I have to restate the task/output format each time.
  • App side chats are closer because I can have multiple side chats, but bringing selected results/context back to the main thread still requires copy/paste.

It would be useful to run a reusable workflow off-thread, inspect it while it runs like an agent, then bring back the useful result.

Concrete examples:

  • commit flow: inspects status/diff/log, checks for secrets, stages/commits, then I can bring back only the commit hash/message or discard the side session
  • review flow: explores the diff and surrounding code, follows call paths, checks tests/config, then I can bring selected findings + file refs back to the main thread
  • similarly test triage: runs or inspects test output, chases logs/failures, narrows likely cause, then I can bring back failing tests + next steps
  • app/log watcher: runs the app, watches logs/browser output, filters noise, and can stream relevant errors/regressions back to the main thread

The main thread should keep the durable task context; noisy side work should stay off-thread unless I choose to bring something back.

Additional information

Related to #22943 - that issue is close because it asks for forked skill execution. This request is broader on the interaction model: parallel side work that can use main-thread context, stay inspectable while running, and hand selected results back without filling the main conversation.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 3 months ago

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

  • #23713
  • #24398
  • #24107

Powered by Codex Action

johnastinnett · 3 months ago

This request matches the workflow I’ve been exploring from a slightly different angle. You can actually accomplish this with a few mutations, but not recommended.

The key primitive I think makes this work is: a side session should be a normal, inspectable, sidebar-visible thread, but also be attachable to a parent/orchestrator thread as a routable lane.

A concrete example:

  1. Open a normal Codex session at your/project/orchestrator/ so it loads the orchestrator AGENTS.md.
  2. Open another normal Codex session at your/project/reviewer/ so it loads the reviewer AGENTS.md.
  3. Open another normal Codex session at your/project/release/ so it loads the release/CI AGENTS.md.
  4. Attach the reviewer and release sessions to the orchestrator with an App Server attachment RPC.
  5. In the orchestrator thread, say something like:
  • “Send the current diff to reviewer for a review pass.”
  • “Send the failing CI log to release and ask it to triage.”
  • “Ask reviewer to inspect the patch, then bring back only required findings.”
  • “Ask release to watch the test output and report only regressions or likely root causes.”

That gives the shape this issue is describing:

  • the main orchestrator thread keeps durable task context
  • noisy review / CI / log work happens in separate visible threads
  • those side threads remain inspectable while they run
  • each side thread can load its own folder-scoped AGENTS.md
  • the orchestrator can route work to them without copy/paste
  • only the useful result needs to be brought back to the main thread
  • each side lane can be kept, reused, archived, or discarded independently

Two more examples:

A commit workflow:

  1. Open your/project/orchestrator/ for the main task.
  2. Open your/project/commit/ for a commit-focused lane with its own AGENTS.md.
  3. Attach commit to orchestrator.
  4. Tell the orchestrator: “Ask commit to inspect status/diff/log, check for secrets, stage the intended files, commit, and return only the commit hash and message.”

A long-running app/log watcher:

  1. Open your/project/orchestrator/ for the main task.
  2. Open your/project/runtime-watch/ for a runtime/log watcher lane with its own AGENTS.md.
  3. Attach runtime-watch to orchestrator.
  4. Tell the orchestrator: “Ask runtime-watch to run the app, watch logs/browser output, and report only relevant errors, regressions, or readiness signals.”

In other words, this does not necessarily need to be modeled only as /side or only as a disposable spawned subagent. A normal app/desktop thread already has a lot of the right lifecycle and inspectability properties. The missing primitive is being able to attach that existing thread to a parent as an addressable worker lane.

I opened a related narrower issue for that primitive here:

https://github.com/openai/codex/issues/24398

And I put together a reference branch exploring the App Server side of it:

https://github.com/johnastinnett/codex/tree/codex/thread-attachments-rpc

The branch does not implement the full UX described in this issue, like skill-packaged side workflows or a polished “bring selected results back” interaction. But I think it supplies the lower-level substrate that makes those flows much cleaner:

  1. create or manually open normal sidebar-visible threads in the right folders so each gets the right scoped instructions
  2. attach those threads to the main/orchestrator thread as persistent lanes
  3. run noisy side workflows in those lanes
  4. inspect the lanes directly while they work
  5. have the orchestrator pull back only the summary, commit hash, review findings, failing tests, or other selected result

So I think #24398 is complementary to this request: this issue describes the higher-level interaction model, while the attachment primitive gives App Server/Desktop a clean way to make those side sessions durable, inspectable, folder-scoped, and routable without local state surgery.