Skip to main content
A runtime is the engine an agent runs on. Rundock supports two: Claude Code (Anthropic), the default, and Codex (the official OpenAI CLI). Both run locally on your machine under your own subscription; Rundock starts them, watches them, and shows you their work. You can mix runtimes freely in one team: a Claude orchestrator delegating to a Codex specialist is an ordinary conversation.

​
Choosing a runtime per agent

Every agent runs on Claude Code unless its file says otherwise. To run an agent on your ChatGPT plan, add one line to its frontmatter (or ask Doc to do it):
Two rules worth knowing:
  • The workspace orchestrator always runs on Claude Code. Specialists are free to run on either runtime.
  • Leave the model field out of Codex agents. Your ChatGPT account’s default model applies automatically. Claude model names (opus, sonnet, haiku) are not valid on Codex; if a Codex agent is given a model its account does not offer, Rundock shows a card explaining exactly that, with the fix.
For Claude Code agents, model: takes any model identifier your runtime serves. On a standard Claude Code setup that means opus, sonnet or haiku. An agent file that names no model runs on whatever your runtime already defaults to: Rundock does not pick one for you. Rundock does not check the value. It passes what you wrote to the runtime, which is what makes the next section possible.

​
Models through a gateway (Claude Code)

This section is about Claude Code agents. Codex agents take their model from your ChatGPT account, so leave their model: field out. If your models reach you through a gateway or proxy rather than directly, the names will be your gateway’s own, in whatever form it uses, for example my-gateway/claude-model-id. Put that identifier in the agent’s model: field and Rundock passes it through untouched. When you would rather not name a model at all, leave model: out or set it to inherit. They do the same thing: Rundock asks for no particular model and your runtime applies whatever default it already resolves for your machine. This is what the agents Rundock creates for you use, including Doc, so a workspace works on the first message without anyone having to know which models your setup serves. One consequence worth knowing: every agent set to inherit runs on the same model, the one your runtime defaults to. If you want a stronger model for an orchestrator and a faster one for simple work, name those models per agent instead.

​
What each subscription covers

Rundock’s first-run setup detects the Codex CLI and, if it is present, offers an optional step to sign in to Codex; you can also run codex login yourself in a terminal, now or later. Settings show each runtime’s status.

​
Permissions and sandboxing

The two runtimes protect your machine differently, and Rundock is honest about the difference:
  • Claude Code agents use Rundock’s permission system: terminal commands and connector actions appear as cards you approve or deny, with low-risk read-only commands approved automatically.
  • Codex agents stream their replies as they think, over one long-lived process, and run inside Codex’s own sandbox for reads and writes in your workspace. Any action that needs extra access, a command outside the sandbox or a write it cannot normally make, raises the same permission card you approve or deny, mid-turn, on every platform. An ignored request is declined automatically so a turn never hangs.
Keep agents inside this workspace, in Settings under Permissions, is Rundock’s switch for Claude Code agents on macOS. Where Codex is the workspace’s default runtime, that row reads Status unknown, because Codex runs its own sandbox from its own config file and Rundock cannot confirm whether it is active. A workspace whose agents use both runtimes shows a read-only row for Codex, Keep Codex agents inside this workspace, beneath the Claude Code one. See Keep agents inside this workspace.

​
Codex file writes on Windows

On macOS and Linux, the Codex sandbox enforces workspace-only writes natively. On Windows, Codex needs its native sandbox enabled before it can write files directly. One config line does it: add this to %USERPROFILE%\.codex\config.toml:
unelevated needs no administrator setup and suits knowledge workspaces; elevated is Codex’s stronger isolation mode (dedicated sandbox users, firewall rules) and worth considering if your workspace holds sensitive material: it requires a one-time administrator-approved setup. Without that config line, Codex agents on Windows are never silently read-only: their file writes arrive in the conversation as permission cards showing the exact path and content, and the file is written only when you approve. Settings point you at the config line whenever it applies.

​
Runtime status in Settings

The Runtimes card in Settings reports what Rundock can actually verify, and nothing more:
  • Not installed: the CLI was not found on this machine.
  • Not signed in: the CLI is installed, but no sign-in credentials were found. Run its login command.
  • Signed in: the CLI is installed and credentials exist. Rundock checks that a credentials file exists: it never reads its contents.
  • Installed (grey): the CLI is present and sign-in state cannot be determined either way.
Hover any status for the evidence behind it.

​
When something goes wrong

Codex failures explain themselves instead of showing raw errors:
  • Signed out: a card says so and names the fix (codex login), and resending your message after signing in continues the same conversation.
  • Model not available: a card names the configured model and the fix. Remove the model: field to fall back to your ChatGPT account’s default, or name a model your plan includes.
  • Plan limit reached: a card explains the limit is temporary and your conversation is safe; Claude agents are unaffected.
Anything else surfaces with the runtime’s verbatim message attached, so nothing is hidden.