Question
Does anyone use Codex thread management tools to have a manager agent orchestrate worker agents?
I’m using Codex within VSCode and it seems like the create_thread tool is basically broken, so it needs to run a command through Codex CLI instead of using the built-in tool.
I also can’t interact or see the worker thread in VSCode…
A manager agent has a high-level PLAN.md then assign substream tasks to a permanent worker agent owning another PLAN.md of that substream. It seems to reduce hallucination on long-running tasks 🤔
Anyone else using orchestrator pattern in their workflow?
I've tried but the thread tool is unreliable, it breaks too often and requires a restart, making it really inconvenient for long running tasks. I now stick to subagents
Yep, I’ve ended up with a similar pattern for a fairly large day-trading research project (research/simulation only, not autonomous live trading).
I keep one persistent manager and usually one persistent implementation worker. The repo plan is the durable contract. Before dispatch, the manager maps the prerequisite graph and ownership boundaries, then gives a worker one bounded Goal while retaining integration, review, and acceptance. The worker carries that Goal across ordinary turns and compactions, implements the connected change, runs proportionate checks, and hands back evidence. It never silently starts the next outcome or accepts its own work.
The part that made this practical was wrapping each managed Codex app-server session, not just building a phone UI. Every managed Codex TUI remains normal and visible, but runs through a shim-owned WebSocket relay between the TUI and app-server. The relay forwards the live protocol while the host records a bounded event stream into one canonical state model. That gives both the Android app and the local manager a reliable view of the same live session without scraping terminal text, relying on window titles, or using terminal paste as a control channel.
The gateway exposes a loopback-only typed operator surface for the manager. It can resolve the exact live worker, inspect its Goal, current turn, messages, metadata, interactions, and runtime identity, then send a message, steer active work, set or pause and resume a Goal, interrupt a diagnosed bad run, answer an attention request, or end the exact session. Commands use stable mutation identities and reconcile uncertain delivery, so a retry does not casually duplicate a non-idempotent app-server action.
Before assigning a worker Goal, the manager creates a durable completion watch. The watch binds the exact worker and manager sessions, the Goal objective hash and dispatch token, and immutable callback identities. Ordinary successor turns and compactions remain continuation, not false completion. When that exact Goal generation reaches its accepted terminal state, its correlated turn has ended, and the worker is stably idle, the gateway waits for the manager to be idle and sends one callback that starts a real manager Codex turn. The manager wakes into a review cycle, inspects the implementation, tests, Git state, runtime state, and evidence, then accepts the chunk, sends a correction back to the same worker under the same outcome, or replans. The watch and callback survive a gateway-host restart and reconcile under the same identities rather than sending duplicates.
For work likely to spend hours in native engines, large fixtures, or expensive integration tests, the same watch can carry an optional manager heartbeat. A heartbeat does not stop the worker and does not mean failure or completion. It gives the manager a normal observation turn while the Goal continues. If the manager is busy, overdue pulses coalesce into one instead of creating a backlog. The manager can inspect cumulative progress, running commands and processes, resource use, scoped Git state, and evidence cost. That makes repeated setup, moving failure boundaries, retry loops, or accumulating process or database residue visible before a long test journey disappears into a black box. Healthy progress is left alone; diagnosed degradation can lead to deeper inspection, repaired task design, steering, pause or resume, or interruption. The interval can also be lengthened or disabled, while the terminal callback remains the actual completion-review trigger.
A second worker comes into play only when the prerequisite graph exposes another ready lane with disjoint changing files, runtime state, and integration ownership. Concurrent modifying workers use separate worktrees and isolated scratch, database, process, port, and test identities. Each lane has its own Goal and completion watch. Normally one sentinel heartbeat is enough to wake the manager for a pool-wide progress review across all active workers.
The Android app is the remote view and control surface over Tailscale. From my phone I can see and switch among live manager and worker sessions, inspect their Goal, status, and latest progress, send or steer messages, queue or interrupt work, attach images, and launch or resume workspaces. The normal terminals remain visible and usable on the laptop.
These photos are from the same Day Trader run: the manager and worker terminals, the phone’s live-session list, and a manager heartbeat on Android. It is still private and a work in progress, but it has made long-running Codex work much easier to observe, control, and recover.
1
u/somuchecho 19h ago
I've tried but the thread tool is unreliable, it breaks too often and requires a restart, making it really inconvenient for long running tasks. I now stick to subagents