In Short

  • Problem: Claude Code Dynamic Workflows provide a convenient shape for launching several sub-agents, keeping noise out of the main conversation, and synthesizing the result.
  • What I tested: a local Codex prototype with a Node runtime, fake workers, real read-only codex exec workers, an MCP interface, a skill, and a plugin manifest.
  • Result: the lab now passes offline tests, installs through a Codex marketplace, runs authenticated read-only workers, completed one comparison campaign on BannerGenerator, and then showed its limits on Hermes.
  • Lesson: the useful part is not that the agents become smarter. It is that the workflow keeps prompts, commands, logs, status, identity, and synthesis in one artifact tree.
  • Repo: the lab is published as an experimental artifact. I am pausing it after version 0.1.12, because multi-agent campaigns are too token-heavy to keep iterating blindly.

Why I Wanted To Try

The starting clue was Michaelliv/pi-dynamic-workflows: instead of asking one agent to carry a whole job in one conversation, let it write a small workflow script, mark phases, launch workers, gather returns, and send back a synthesis.

Claude Code now has a native version of that idea with Dynamic Workflows. I was not trying to copy the product. I wanted to know whether Codex could recover the same useful shape with the surfaces it already exposes: codex exec, MCP, skills, and plugins.

The first answer was too optimistic. Yes, a local runtime can orchestrate several Codex runs. But in the surfaces I could use here, I did not find a simple equivalent to an embedded registerTool(). Codex has to be treated as an external worker, not as a library hidden inside the workflow.

What The Lab Contains

The lab repository contains:

  • a TypeScript runtime;
  • a codex-flow CLI;
  • a stdio MCP server;
  • a fake codex binary for offline tests;
  • a skill wrapper;
  • a plugin manifest;
  • an example workflow;
  • a README and RESULTATS.md.

That was enough for the first pass. The second pass had to prove that the same shape could survive real Codex workers instead of only fake ones.

What Worked

The offline path worked first. The runtime can validate a workflow, launch fake workers in parallel, collect results, and expose MCP tools such as validate, submit, status, cancel, result, and artifacts.

The reference workflow stayed deliberately modest: a read-only repository review with three fake workers, one for architecture, one for tests, and one for security. That is not spectacular, but it avoids the usual trap of starting with a workflow that writes everywhere before the isolation has been proven.

Then the real-worker path started to work. Version 0.1.4 fixed local auth propagation by copying only auth.json into a temporary worker CODEX_HOME. Version 0.1.5 changed MCP submit into a detached submit-and-poll flow, so a long workflow no longer has to finish inside one Codex app tool call.

The most useful campaign so far remains a four-role review of BannerGenerator. The Dynamic Workflow run completed in 185,635 ms, wrote 27 local artifact files, kept the target repo clean, and produced comparable findings to a manual multi-agent run. In that campaign, the manual roles were still excellent, but the workflow had better reproducibility and traceability because the prompts, commands, logs, policy hash, worker identities, and summary were all preserved together.

The findings were ordinary but useful: a tracked .codex-browser/auth.json risk, ignored-but-local .env secrets, gaps between make targets and the real frontend or backend test suites, large coordination modules, and some documentation drift.

The next test, on Hermes, was more useful as a failure than as a benchmark. The preflight eventually passed, but both measured workflows were invalid: worker output was too large, results were suppressed by artifact hygiene, last-message fallback was used, and the target repository git status changed during the campaign. In that diagnostic run, the routed workflow even used more tokens than the classic workflow. So I cannot use it as evidence that routing reduces cost.

What Is Still Weak

The important missing pieces are still the real ones:

  • write-mode worktree behavior;
  • process-tree cancellation;
  • formal artifact DLP;
  • lower-noise worker output capture;
  • strict timing and token measurements for each method, on a target repository whose git status stays stable for the whole campaign;
  • janitor and resume behavior;
  • repeat campaigns on more repositories.

Those are not details. They are the difference between a neat local demo and a tool I would trust around real repositories.

The CODEX_HOME question is the most uncomfortable one. Reusing a real Codex home can expose more than authentication: plugins, MCP configs, caches, telemetry, histories, or connectors. The prototype therefore keeps a temporary HOME and isolated CODEX_HOME by default. That is safer, but it makes real Codex runs harder.

There is also a cost point I do not want to hide. This lab consumed a lot of tokens: several failed campaigns, manual comparison agents, real multi-worker runs, and follow-up fixes. On Hermes, both measured methods went above three million tokens each without producing usable benchmark evidence. The next proper benchmark needs a smaller scope, a stricter output contract, and a clear stop rule as soon as validity drops.

Where I Am Pausing

Version 0.1.12 is a reasonable temporary stopping point. It adds the things the last diagnostic made obvious: JSON schemas in the example workflows, bounded findings, no source excerpts in worker results, and a pre/post git-status guard when artifacts are written outside the target repository.

I am keeping the repo public because the useful traces are there: the runtime, the plugin, the docs, the benchmark helpers, and RESULTATS.md. But I am not going to keep running long campaigns right now. Before another run, the test needs to be smaller, quieter, and run under an explicit token budget.

What The Lab Repo Shows

The public repo is there to inspect the first shape: the TypeScript runtime, CLI, MCP server, skill, plugin manifest, fake codex binary, reference workflow, README, and RESULTATS.md.

It is useful for checking whether Codex can recover the main Dynamic Workflows pattern with available surfaces. It is now more than a fake-worker demo: marketplace install, auth propagation, MCP submit/poll, traceable artifacts, and stricter validity rules have been validated. It is still not a production plugin, a refactor automation tool, a proof that routing saves tokens, or a safe way to let several agents modify a repository on their own.

The Lesson I Keep

The easy part is making JavaScript launch workers.

The hard part is deciding what a worker is actually allowed to do. A dynamic workflow can quickly become a machine that launches too many agents, too many commands, and too many logs. The policy therefore has to live outside the model: agent count, duration, output size, sandbox, writable paths, allowed models, available secrets, cancellation, and cleanup.

In this lab, the script is not an authority. It is an execution request under an immutable policy. That is probably the most important difference from a macro or a reusable prompt.

That is why I keep the lab public but experimental. It is useful evidence, not an installation recommendation.