Don’t rebuild it.Just use Codex.

Put Codex Desktop in a container. Bridge it over HTTP. Keep its native browser, computer use, threads, and upgrades intact.

One machine · No control-plane ceremony · Native capabilities
JustUseCodex banner with three bell-curve meme characters
HTTP-nativeOne clean API
Real Codex DesktopNot an imitation
Built-in browserCapabilities intact
Persistent threadsContext stays put

Desktop power.
Worker shape.

The shortest path to a capable Codex worker is the one that keeps Codex itself in the loop. JustUseCodex wraps the native app in a container and gives your code a straightforward HTTP surface.

01 / CONTAIN

Run the real app

Codex Desktop lives inside an isolated worker with its own persistent state.

02 / BRIDGE

Talk over HTTP

Send turns, inspect status, manage threads, and invoke the native runtime through one API.

03 / USE

Build the thing

Connect your app, automation, or agent. The browser and computer-use surface come along.

Shimex

Use any inference providers you want in Codex Desktop.

Explore Shimex ↗

No SDK
required.

If it can make an HTTP request, it can use your worker. Start a turn with JSON and follow the run until Codex is done.

REQUEST
curl -X POST \
  http://127.0.0.1:4580/v1/desktop/turns \
  -H 'Content-Type: application/json' \
  -d '{
    "prompt": "Fix the failing test"
  }'
RESPONSE · NDJSON200 OK
{ "type": "turn.started" }
{ "type": "item.completed",
  "item": { "type": "agent_message" } }
{ "type": "turn.completed",
  "threadId": "thr_..." }

Bro, you're not going to out-build OpenAI's coding product from your bedroom.

They have an army of engineers and a mountain of GPUs. That annoying missing feature? They'll probably ship it before you finish rebuilding their entire stack.

Put Codex Desktop in a container. Expose it over HTTP. Go work on the thing people might actually pay you for.

Make your first request →