Codex Process Jobs
Codex Plugin: Durable detached local process jobs for Codex
10 followers
Codex Plugin: Durable detached local process jobs for Codex
10 followers
A free, open-source Codex plugin for long local builds, tests, benchmarks, inference runs, and repairs. CPJ detaches the process, releases the conversation, records bounded output, and returns completion to Codex for inspection.
Codex Process Jobs is a boring, free, open-source plugin that exists to have the Codex agent detach from long-running processes instead of polling them and holding the turn. This is more like the default behavior in Claude Code. Token usage is approximately neutral unless you opt for the `--report` completion mode, in which case it can be lower than standard behavior. I'm looking for feedback and testing, especially in real-world and edge cases.
CPJ relies on user-enabled hooks and bundled skills to force Codex to detach processes likely to take longer than a minute to background, then wakes the agent when the job is finished, along with a report. Live completion works in Codex App and the VS Code extension. CLI/TUI defaults to a best-effort desktop notification and surfaces completion on the next eligible turn, but it cannot render a live inserted completion turn.
GitHub: https://github.com/joelfarthing/...
OpenAI Marketplace: https://chatgpt.com/plugins/plug...
Pythagora
@joel_farthing Really exciting launch. The focus here is clear and the product looks polished—congrats! 🚀
the bounded output logs are a lifesaver on long builds, would love a per-job rerun button right in the completion card so i can re-trigger a failed benchmark without digging through job history
@ndominic_ong That is a terrific idea, and I'll fold it into the next release. A UI button requires an MCP server, which is beyond the scope of what I want to require of users, but here's how the updated flow should look:
1. Add a safe rerun controller command and skill.
2. On failed jobs, let the completion response recommend: “I can rerun the same invocation.”
3. The user can answer “rerun it,” producing a new tracked job.
This would reproduce the invocation, but not necessarily the original environment. Source files, environment variables, dependencies, and external state may have changed since the first run.
Thank you for the excellent suggestion!
@ndominic_ong CPJ 0.2.7 now includes `rerun`, and Codex will ask if you'd like to do that after a failed job.
Interesting approach detaching long inference runs from the Codex conversation loop — do the detached jobs still route through whatever endpoint Codex is configured against (e.g. a custom base URL), or do you shell out separately? Curious how you handle bounded output when a run streams a lot of tokens.
@tian_yi1 Thanks for the question! CPJ isn’t an inference proxy. It launches the exact command as an ordinary detached local process: direct argv by default, or an explicit shell mode when requested. The process inherits the launching environment, so if your inference runner honors a custom base URL or endpoint configuration, it continues using that. CPJ doesn’t rewrite or route those requests itself.
Stdout and stderr are stored separately in private local bounded logs. Each stream defaults to a 16 MiB cap, retaining the newest output with a truncation marker. Model-facing reads are bounded again: 64 KiB normally, 8 KiB/four recent lines for lightweight status, and at most 1 MiB with --full. Incremental cursors allow following high-volume output without feeding the entire stream back into Codex.
Finally something for those long compile runs that don't need my whole context held hostage. Detaching the process and just letting Codex check back in when it's done is honestly the kind of obvious-in-hindsight thing I wish existed sooner.