I use Claude Code, Codex, and open models for different parts of development. I wanted a single workspace where I could keep their own runtimes and accounts, inspect their work, and let them hand tasks to one another.

That is why I built AnyCode. I use it for day-to-day work and to coordinate agents across my projects. Getting those agents to work in one app meant learning how their harnesses actually work: the protocols that carry a turn, how sessions resume, what an approval is on the wire, and what happens when a process disappears.

AnyCode demo: ask for a change, approve the edits, check the preview, review the diff, commit

A real run of the Native loop on GLM-5.3. Typing is automated and agent work is sped up; sped-up stretches are marked in the video.

The workspace is not the agent

AnyCode is an open-source (Apache 2.0) desktop app for macOS, Windows and Linux. A session runs on one of three engines: the Claude Code CLI, the Codex CLI over its app-server protocol, or AnyCode's own Native agent loop. Around the engine the workspace stays the same: transcript, tool calls, permission prompts, terminal, context usage, MCP servers and Git review. What a session can do still comes from its engine; an action the backend can't perform is disabled rather than shown as working.

Claude Code and Codex run locally under your own accounts; authentication is handled by the CLIs. For the Native loop you bring a connection: a coding subscription such as GLM Coding Plan, MiniMax or Kimi, an API key, or an OpenAI- or Anthropic-compatible endpoint, local ones included.

Hosting a coding agent

A coding agent is a loop: it receives a conversation, picks tools, gets results back, sometimes asks for permission, and continues. Hosting someone else's loop means translating that lifecycle without losing what the engine meant.

The two CLIs speak very different protocols. Claude Code runs headless with stream-json on both stdin and stdout, resumes a session with --resume, and sends permission requests back over the same stdio channel. Codex's app-server speaks JSON-RPC: thread/start and thread/resume for sessions, turn/start and turn/interrupt for turns, and separate approval requests for commands and file changes. A session also outlives any single response: it gets interrupted, closed and resumed, or parked on an approval, and the adapter has to keep the engine's own session identity intact through all of it.

Trust is part of the translation. In a folder you haven't trusted, AnyCode starts Claude Code with user-level settings only, so hooks defined in the repository's own Claude settings never reach the CLI.

Both CLI adapters are pinned against recorded protocol fixtures. Those tests check adapter changes against captured messages and can catch regressions before a release. Checking a pin against a newly released CLI is a separate opt-in run against the real binary.

The Native loop taught a different lesson. Some providers expect the reasoning they returned earlier to be sent back on later requests; others reject it. By default AnyCode replays it, and if a provider rejects it, retries once without it and leaves a notice in the transcript. On the Responses transport only encrypted reasoning can be replayed; text-only reasoning there has no documented replay form. One conversation view doesn't make provider protocols interchangeable.

Recovery belongs in the harness too. Messages queue while an agent is busy. A Claude session whose process exits while idle resumes automatically; if recovery fails, unsent messages are kept and the app explains how to restart. Reports from background child sessions survive a session restart and are retried afterwards.

Letting sessions work together

The Sessions API lets agents open sessions and talk to them. Sessions running on different engines inside AnyCode can communicate through it, and agents outside the app can connect too. It is a local MCP endpoint, bound to 127.0.0.1 and protected by a token, that runs while the app is open.

This currently needs setup: enable the API and connect it to the calling agent as an MCP server. Settings provides a ready MCP config for Claude Code or Codex. Running inside AnyCode does not automatically give a session these tools. Once connected, an agent can:

  • list the sessions you share (list_sessions) and read their status and latest answer;
  • send a message (send_message), queued for the next turn or, in a Codex session, steering the running one;
  • wait for the turn that took the message (wait_for_result), or stop a running turn (cancel_turn);
  • open a new session (create_session) in a project you allowed, choosing the engine, model, reasoning effort and a first message, and close it when done.

For example, a Claude Code session could ask a Codex session to review a change. With the MCP connection and project permissions set up, the exchange could look like this:

  1. Call create_session with engine: "codex" and the project path; keep the returned session id.
  2. Once the session is ready, call send_message with mode: "next_turn" and a request such as: "Review the current diff for correctness. Report findings with file and line references; do not edit files."
  3. Pass the session id and returned message id to wait_for_result to collect that turn's answer.
  4. Use the findings to revise the change, send a follow-up to the same session, and close it with close_session when finished.

Each session keeps its own engine, tools, context and permission settings. The caller uses it as a subagent and manages its lifecycle.

Messaging is asynchronous. wait_for_result waits up to 120 seconds per call; if it returns pending, the caller waits again. Acceptance of a message and completion of the receiving turn are separate events. The API tracks both, so the caller can wait for the answer to a particular request rather than mistake a delivery receipt for finished work.

Access is opt-in at every level. Sharing is a per-session switch, off by default. Agents open sessions only in trusted projects where you ticked "Allow agents to open tasks here", at most eight at once. Approvals have their own switch, External approvals, also off by default: with it on, a client can allow or deny pending tool requests one at a time, never "always allow".

This complements the app's own delegation, where a parent session starts background children, possibly on another engine, and Orchestrate mode (Native and Codex tabs) turns a tab into a read-only supervisor over planner, executor and reviewer roles. The same Sessions API also works for a Claude Code agent in a terminal, a separate Codex client, or a script.

Remote access on the same API

A remote interface is just another client. The repository includes a Telegram bridge as an example plugin: AnyCode starts and supervises it, and it connects one private chat to your shared sessions. You pick a session, any text becomes a new turn whose answer comes back to the chat, /new opens a session, and approvals arrive as Allow and Deny buttons where External approvals is on. It uses only Node built-ins, so it doubles as a template for a bridge to any other channel.

The desktop app is split in a similar way: a sandboxed renderer on one side, host processes that run the agent sessions on the other, and a typed message protocol between them. That separation could support a backend on a VPS with the desktop as a thin client, though remote transport and deployment would take further work. It is an architectural possibility, not a shipped feature.

Building the workspace with agents

Much of AnyCode was built with the kinds of agents it runs. I decide what to build, split the work, choose which agent gets each piece, and review the result. Agents write and review changes; I am responsible for what lands. When a change touches a protocol or a permission boundary, I lean on type checks, tests, the protocol fixtures and a development-only GUI smoke workflow rather than on an agent's report.

Where it stands

AnyCode is in alpha, at v0.0.90. Storage, APIs and UI can still change without compatibility guarantees. Builds are currently unsigned; see the installation instructions for your platform. On the Native side, Z.AI, Kimi, DeepSeek, MiniMax and Xiaomi MiMo have seen live use; other providers less.

If you try it, run one ordinary task through AnyCode and tell me at which step you wanted to go back to your usual tool. Downloads and source are on GitHub; issues and contributions are welcome.

This post was drafted with AI assistance and edited by me.