Codex users report subagent, MCP, and canary deploy workflows

• Practitioners are using Codex less like a one-shot coding assistant and more like a persistent worker, with WesRoth's workflow-orchestration post describing scheduled automations, thread reuse, and persistent memory, while embirico's subagent workflow describes keeping one thread alive and dispatching parallel work into it.
• The control surface is getting more modular: mattrickard's CLI screenshot shows computer-use injected into Codex CLI as an MCP tool, and kevinkern's MCP roundup lists at least seven open source browser and desktop automation projects that can slot into the same pattern.
• Teams are already wrapping those capabilities in their own harnesses, from _lopopolo's markdown-runbook setup for versioned automations to nummanali's cmux setup for Codex and Claude-to-Claude coordination.
• The most concrete production-style workflow in the evidence came from _lopopolo's canary-deploy post, where Codex proposed a separate Tailscale identity to test a new robot-vacuum build before cutover, and the follow-up result reported the flow working end to end.

You can read the robot-vacuum canary writeup, inspect a plain-language Codex skill, browse the multiautoresearch repo, and skim Playwright MCP alongside browser-harness. The weirdly consistent pattern across all of them is that the useful unit is no longer a single prompt. It is a thread, a runbook, or a harness that sticks around long enough to accumulate context.

The official framing in WesRoth's post is scheduled automations, thread reuse, and persistent memory. The user reports are already pushing that into longer-lived operational loops.

embirico's post describes a thread that stays active and gets new work via automations or follow-up prompts. dkundel's teammate description makes the same point from another angle: plugins, CLIs, thread automations, and memories let Codex keep enough context around that prompts can stay vague.

Subagents show up here as a practical decomposition tool, not a demo flourish. embirico describes explicitly asking for parallel subagent work inside an already-running thread.

ben_burtenshaw's hands-on setup is the clearest public pattern for that style of work:

1. a researcher agent searches papers and proposes hypotheses,
2. a planner agent maintains the experiment log,
3. worker agents edit scripts and launch jobs,
4. a reporter agent tracks events and metrics.

The same thread adds two orchestration constraints that feel reusable beyond research: the planner should not do the task itself, and workers need shared storage plus a stable dependency layer so handoffs do not dissolve into environment churn.

One of the more revealing screenshots in the set is mattrickard's, which shows computer-use exposed inside Codex CLI as an MCP tool with actions like click, drag, scroll, set_value, and type_text. That collapses the gap between the desktop app's UI agent and the CLI surface people already script around.

kevinkern's roundup makes the broader ecosystem visible. The list spans browser-harness, native-devtools, agent-browser, browser-echo, Peekaboo, a Tauri MCP server, and Playwright MCP. In practice, the interesting split is:

• browser control: browser-harness, agent-browser, Playwright MCP
• desktop and native app control: native-devtools, Peekaboo, mcp-server-tauri
• observability: browser-echo

nummanali's cmux setup pushes the same idea further by using a terminal control layer as the message bus between Codex and Claude, then writing the protocol into AGENTS.md so the arrangement survives the current session.

The best evidence here is not that Codex can edit code. It is that one user let it design a verification plan.

According to _lopopolo's post, the hard part of upgrading a custom Tailscale build on a robot vacuum was verification, so Codex proposed a canary Tailscale identity for the new binary before production cutover. the later update says the agent analyzed upstream changes, applied new build tags, deployed via the canary mechanism it designed, validated SSH reachability, and then performed the production cutover from v1.90.8 to v1.96.4.

The full writeup in the Hyperbola post matters because it turns a flashy tweet into a repeatable pattern: isolate identity, validate reachability, then promote.

The rough edge in these workflows is not prompting. It is secret handling.

_lopopolo's request asks for Codex environments that can securely manage env vars so an agent can operate Home Assistant without pasting tokens into chat. In reply, _lopopolo's follow-up says the ideal setup is harness-level injection and safety controls so tokens never enter model context or the repo at all. That is a much stricter requirement than ordinary desktop automation.

Capacity is moving too. _lopopolo's GitHub Actions comparison says Codex usage outlasted their monthly Actions budget, while Boris Cherny's reply screenshot shows Claude Code lead Boris Cherny saying Anthropic had no plans to roll back a subscriber rate-limit increase. The story is partly about agents getting more capable, but also about the surrounding harness, quota, and secret-management layers finally becoming the thing people talk about in public.