feat: API support to complement the CLI
Resolved 💬 9 comments Opened Apr 25, 2025 by thingersoft Closed Sep 3, 2025
💡 Likely answer: A maintainer (tibo-openai, collaborator)
responded on this thread — see the highlighted reply below.
Hi team,
first of all, thank you for the great work on this project!
I was wondering if there are any plans to add an API alongside the CLI. Having a programmatic interface would make it much easier to integrate the tool into larger systems or automate it in non-interactive environments, such as CI/CD pipelines or backend services.
An API would open the door to:
- Easier integration with other tools and platforms
- Automation of workflows that currently require scripting around the CLI
- Improved support for web-based or remote clients
Is this something already being considered? If not, would a contribution in this direction be welcomed?
Thanks again!
9 Comments
Would the idea be to run the main logic as a server and expose something like a REST api for it?
Yes, or alternatively — if adding a full server feels like too much overhead for the core project — even just exposing a programmatic interface would be great, leaving it up to integrators to wrap it however they need.
I went the MCP way, see repo here https://github.com/tomascupr/codexMCP. That’s the standard now imho.
I am happy to add stuff. Just send me a git issue (or PR) :-)
Hi Tomas,
thanks for sharing your project — I haven’t had a chance to look through it in detail yet, but here we’re talking about a lower-level, embedded API that would free integrators from having to go through the CLI (which I assume you had to do in order to wrap Codex within the MCP server tools).
Indeed. But I don't see an issue with CLI. Why do you?
An API makes integration easier in non-interactive or automated contexts, where spawning subprocesses or parsing CLI output can be brittle and less efficient.
Additionally, providing complex input through the CLI often requires escaping, quoting, or using temporary files, which can get messy quickly.
Even better would be to allow running this inside WASM. Now that it's rust, that should be pretty easy depending on the APIs used. Then we can embed its behaviors into any kind of scripted environment.
We are tracking this, and it is now on our roadmap. We hope to make progress on something in this spirit over the next four weeks. I’ll close this out as we are cleaning up old issues and tickets, but rest assured this won’t fall off our radar.