claude-dynamic-workflows-codex: run Claude Code workflows on a local Codex backend

What the skill actually solves for Claude Code users

Claude Code's dynamic-workflow scripts are a way to fan a task out across subagents, but the subagents are Claude's own. This project swaps that execution layer: Claude still authors the workflow, and the workers that run it are Codex (GPT) agents on a local codex app-server. The README frames the split plainly, describing it as a Claude Code skill where you type /codex-workflows <task> and a fleet of Codex agents fans out across the work.

The audience is narrow and specific. You need the codex CLI on your PATH and you need to be logged in. If you are already paying for Codex access and also using Claude Code as your editing surface, this lets the orchestration happen in the tool you like while the token spend lands on the other backend. The README names codebase audits, large migrations, cross-checked research and idea generation as the intended workloads. Those are all tasks where a single context window is the bottleneck, not tasks where a single answer is the goal.

One design detail worth noting early: the skill is manual-invoke only. The README states Claude never auto-triggers it. That is a deliberate choice against ambient orchestration, and it means a stray prompt will not silently spawn dozens of agents.

How a rough sentence becomes a workflow script

The pipeline has five stated steps, and the interesting ones are the second and third. First Claude preflights Codex, confirming the app-server is reachable and noting the latest frontier model. Then it compiles your rough intent into a harness: it picks the scale, archetype and pattern, builds a task contract, and states its assumptions. The README is explicit that no external metaprompt is needed.

Step three is the part that matters for anyone who has been burned by opaque agent frameworks. Claude authors a workflow script into your project at ./<name>.workflow.js. That file is yours. You can read it, tweak it and rerun it. The orchestration logic is not hidden inside the skill; it is a checked-in artifact sitting next to your source, which also means it shows up in code review and in git history.

Execution then runs on Codex with every agent pinned to the latest frontier model, which the README gives as gpt-5.6-sol today, and thinking effort scaled to the harness. A small run goes flat with --effort medium. A bigger one uses --auto-effort, where a lone judge or synthesize gate gets the policy's extra-high tier (xhigh) and wide fan-outs floor at high. Finally the outcome surfaces in the conversation as a summary, the script path, and an inline text rendering of the execution map.

Installing the plugin and running a first audit

The recommended install is as a Claude Code plugin, which the README says updates with every push. Two commands, run inside Claude Code:

/plugin marketplace add scasella/claude-dynamic-workflows-codex
/plugin install codex-workflows@codex-workflows

The alternative is a classic skills-dir clone. Either way the skill becomes available as /codex-workflows.

git clone https://github.com/scasella/claude-dynamic-workflows-codex ~/.claude/skills/codex-workflows

Prerequisites are Node 18 or above and the codex CLI on your PATH, logged in via codex login. The README notes there are zero npm dependencies to install. Before running anything expensive, verify the backend is reachable:

npx github:scasella/claude-dynamic-workflows-codex doctor   # → state: ready

The same npx entrypoint exposes the whole CLI surface without installing anything, including run, fleet status|answer, view, map and summarize. For a first real use, pick a task that is genuinely parallel and bounded, then invoke the skill from the Claude Code TUI with a rough sentence rather than a crafted prompt:

/codex-workflows  Audit every route under src/ for missing auth checks

What you should see is a summary, the path to the generated workflow script, and the execution map rendered inline as text. The README's example output shows a header line with a done count, phase count, token total, wall time and model, followed by a per-agent table with model, effort, tokens and wall time, and one-line results underneath each agent.

Inspect a finished run without a Codex account

This is the lowest-friction way to evaluate the project, and it requires no Codex login at all. The viewer is offline and self-contained, and a flagship demo is bundled in the repository.

git clone https://github.com/scasella/claude-dynamic-workflows-codex
cd claude-dynamic-workflows-codex
node runner/bin/view-run.js examples/incident-demo --open

The demo is a fictional checkout-latency incident: a parallel triage, a race of three sessionful root-cause workers where the winner is steered for a confirming second turn and the two losers are cancelled and marked with a ⊘ symbol, and a lone fix gate. Clicking a node shows its full result. Clicking the n+1 worker shows its per-turn timeline. F frames the graph, dragging pans, and scrolling zooms. A Dark/Light toggle sits top-right, and there is a dense Tree layout as well.

Reading the map before installing tells you more about the project's assumptions than the prose does. The visual vocabulary is built around long-lived workers with a turn-chip strip and a ⟳ N badge, around cancellation of losing branches, and around a human() gate that pauses a live run so you can answer it in the page. If those concepts do not match how you think about your own workloads, the tool is probably not for you.

Sessionful workers, races and the fleet supervisor

The v0.2.0 release notes describe sessionful workers, supervised fleets and the fleet protocol. This is the project's main departure from the native one-shot DSL, and the README is direct about it: workers can stay live. You can steer a worker on warm context, race several and cancel the losers, or let a controller adapt the plan as results land.

The practical consequence is that intermediate results stay in the runtime rather than in your context. Your context only sees the final answer, while the runtime holds the loop, branching and intermediate state. For a long audit that is a real difference: the alternative is a context window filling with partial findings from a dozen agents.

The second scale is --multi. Adding that flag makes Claude launch a whole fleet of concurrent workflows and supervise them itself, answering their gates, steering, killing dead ends and forking winners. The README points to a dedicated walkthrough section for this. The repository layout backs the claim: there is an examples/fleet/ directory, a fleet script wired into package.json, and a supervise test in the test list. A fleet test and a supervise test both appear in the npm test chain, so the mechanism is covered by the project's own offline test suite.

Where this is the wrong tool

The hard dependency is the codex CLI, logged in, reachable on your PATH. There is no fallback backend described in the README. If your environment blocks outbound auth to that service, or if you cannot install the CLI on the machine where Claude Code runs, the skill has nothing to execute on. The doctor command exists precisely to surface that state, and it reports state: ready when the handshake succeeds.

Cost and latency are the second boundary. The README's own example output shows a six-agent, two-phase run at 701k tokens and 20m27s of wall time, with individual agents at 140k tokens and 5m16s. Those numbers come from one demonstration workload, not from a benchmark, but they set expectations: this is not a tool you reach for when you want an answer in thirty seconds. A single question that a normal chat turn resolves will cost more here, in both tokens and wall time, than it saves.

The third boundary is maintenance. The repository is not archived, but the last push was on 2026-07-11. The README itself carries an unofficial, community-project disclaimer and states it is not affiliated with OpenAI or Anthropic. For a tool that sits between two fast-moving vendors and pins agents to a named frontier model, that gap is worth weighing: model names and app-server contracts move, and the project's own app-server-contract test is the thing that would catch a break.

Compared with writing the workflow script yourself

The real alternative is not another orchestration product. It is using Claude Code's dynamic-workflow scripts directly, writing the agent() / parallel() / pipeline() / phase() / budget calls yourself against Claude subagents. The README links to the upstream workflow documentation and positions this project against what it calls the native one-shot DSL.

The difference in approach is twofold. On the backend, you trade Claude subagents for GPT agents on a local Codex app-server, which changes who bills you and which model family does the work. On the execution model, you trade one-shot workers for sessionful ones: the native DSL as described here runs agents to completion, while this runtime keeps a worker on a warm thread so you can steer it for a second turn, race several and cancel the losers, or let a controller adapt the plan as results land.

If your workflow is genuinely one-shot, a fan-out where each agent produces an independent result and nothing needs a follow-up question, the extra machinery buys you little. The generated script is still readable and rerunnable, so the cost of trying it is low, but the sessionful features are the reason to prefer this over the native path. Choose based on whether your tasks need a second turn.

Licence, upgrade cost and what to check before adopting

The project is MIT licensed, and package.json carries the same identifier. MIT is permissive: you can use, modify and redistribute it, including in commercial settings, provided the copyright notice and licence text are preserved. That is a statement about the licence text, not legal advice for your situation; if you are redistributing it inside a product, have someone who can read the actual LICENSE file confirm the obligations.

Upgrade cost depends on how you installed it. The plugin route is described as updating with every push, so you inherit changes without a manual step. The skills-dir clone route does not, and if you develop from a clone elsewhere the project provides npm run sync-skill, which pushes the skill surface (SKILL.md, references/, examples/ and runner/) to ~/.claude/skills/codex-workflows in one command. That is the command to run after pulling.

The thing to verify first is the app-server contract, because that is the seam most likely to move under you. The repository has a dedicated app-server-contract test in its npm test chain alongside codex-session and offline tests, and the doctor handshake is the fast check. Run the doctor, run npm test if you have cloned the repo, and open the bundled incident-demo to confirm the viewer renders before you point the skill at a real codebase.

Editorial conclusion

Adopt it if you already run the codex CLI, want Claude Code to author the workflow script rather than you hand-writing one, and need workers that stay live across turns or a supervised fleet of concurrent runs. Do not adopt it if you cannot log into Codex locally, if your task is a single question a normal chat turn answers, or if you need the project to be actively maintained: the last push was on 2026-07-11. Before committing to it, run npx github:scasella/claude-dynamic-workflows-codex doctor and confirm it reports state: ready, then open the bundled incident-demo in the viewer to check that the map, the worker timeline and the human gate render the way your team expects.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. scasella/claude-dynamic-workflows-codex on GitHub