Codex and ACP agents
Besides Claude Code, Handler runs two more kinds of agents: Codex by OpenAI and any agent that speaks the Agent Client Protocol (ACP) — OpenCode, Gemini CLI and dozens of others. These are not model providers: each has its own process, its own login and its own tools. Handler gives them the shared chat screen, permission and question cards, push notifications, the Telegram bot and the agents screen.
Both are owner-only: the agent runs commands on the machine as the server's user, and project scopes or "read only" from access keys can't be explained to it.
Codex
The Codex card is in "Settings → Models and providers", below your own servers and clouds: version, login and logout, command approval for new chats.
Login with a code. A link and a code show up on the screen; you can sign in to ChatGPT from any device, even the phone — no localhost callback needed.
New chat — Codex models are in the common list of the new-chat form, grouped as "Codex · ChatGPT". From there it is a regular chat: the feed, model and effort on the fly, "Plan" mode with questions as cards, /btw. A Codex chat sits in its project next to Claude chats; there is no separate list. A reply survives a Handler server restart: codex app-server lives in its own process.
Instructions like Claude's. Codex itself reads only AGENTS.md; Handler also gives it the project's CLAUDE.md and the shared ~/.claude/CLAUDE.md.
What Codex doesn't have: images in a message, rewind, ultracode and workflows, running on a connected server. Those buttons simply aren't shown in its chat.
Codex sandbox doesn't work in Docker
On Linux Codex isolates commands with bwrap, which won't start under Docker's default seccomp profile. So in Docker a Codex chat runs without the sandbox but with command approval: safe commands like ls Codex runs by itself, the rest come as an "Allow / Deny" card.
ACP agents
The "ACP agents" card is in the same place, below Codex. OpenCode and Gemini CLI are built in: install the agent and log in to it yourself, Handler picks it up. Others come two ways:
- "From the registry" — a searchable catalog of ACP agents: version, description, install method and license. "Install" installs a pinned version with a SHA-256 check (where the registry provides one), next to it "Update to …" and "Remove".
- "Own command" — id, name, command, arguments and environment variables. It runs without a shell.
New chat — an "ACP agents" group in the form's model list. In the chat itself the model, effort and any other settings the agent declares are picked in "Reply mode"; modes the agent doesn't have won't be there.
Permission mode per chat. A new chat starts with approvals: the agent's request to run a command or edit a file comes as the same card as Claude's, with a risk estimate. Dangerous ones still need a second tap.
Handler's tools. An ACP agent gets the same handler MCP as Claude: chats and projects, quick commands, HTML pages, secrets and work memory. The project's and the shared CLAUDE.md go with the first message, and the agent's plan is shown as a list.
A server restart doesn't cut the chat. The agent lives behind its own relay process: a pending permission card or question comes back, and a reply that had started runs to the end.
The agent's old sessions
The "Agent sessions" button next to each agent in the card shows the sessions it ran outside Handler — in a terminal, in an editor. "Import into Handler" brings a session in together with its history; from there it is a regular chat. The agent has to be able to list and load sessions; if it can't, the dialog says so.
An agent starts another agent's chat
Through the handler MCP an agent can start a Codex chat (codex/<model>) or an ACP agent chat (acp/<agent>) — say, hand the second half of the work to Gemini. The new chat gets permissions no weaker than the parent's: the permission mode reaches Codex (as an approval policy) and ACP agents alike. What these engines lack (safe mode, sandbox, extra directories) is refused to the parent outright rather than silently dropped.