One shared CLI is better than four fake integrations
A few people have asked whether Explore only works with Codex.
It doesn’t.
It now works with Codex, Claude Code, OpenCode, and Cursor through the same shared flow.
That matters because I have no interest in building the same integration four times and pretending that counts as product work.
That game never ends. New tool, new wrapper, new setup path, new maintenance tax. Congratulations, you built yourself a compatibility headache and called it strategy.
The better model is simpler:
tool -> Explore CLI -> Explore app/API
One shared contract underneath. The tool is the variable. The workflow is the product.
That is how it should be.
Use Codex if you want. Use Claude Code. Use Cursor. Use OpenCode. Explore should not care which one you picked, and the product should not have to contort itself every time the market finds a new favourite.
So the setup story is now simple: install the Explore CLI, connect your account, and get on with it.
The optional helpers are still there. Fine. They can stay. But they are polish, not architecture.
This is the part a lot of companies still get wrong.
They think “agent support” means they glued one tool onto the side of the app.
That is not agent support. That is a demo.
A real agent-accessible app has a real workflow and a real trust boundary.
In Explore, that path is explicit: export, validate, preview, then apply with the expected fingerprint.
Not “let the agent rummage around and hope it behaves.”
That is the difference.
So yes, four tools now work.
But that is not really the story.
The story is that the tool is becoming less important than the workflow underneath it.
