oto-dock Runs Codex Agents on Your Server

oto-dock is Dimitris’s public GitHub project for a self-hosted “company OS” that runs shared agents on your own server. It deals with the awkward middle space between local coding agents, cloud sessions, API keys, and collaboration. The useful takeaway is narrow: if a Codex agent is going to keep working when nobody is watching, the runtime boundary matters as much as the prompt.

A company OS, in oto-dock’s sense, is a workspace where named agents have jobs, tools, departments, and shared places to land their work. The project connects Claude Code, Anthropic’s coding agent, and OpenAI Codex, OpenAI’s agentic coding tool, to your own Anthropic and OpenAI subscriptions, local models, and server-side sandboxes. That makes it especially interesting for developers already thinking about Codex CLI workflows and where unattended coding work should run. Gemini Workshop is part of Harness Institute.

See what oto-dock is actually trying to run

The Show HN pitch was not “a prettier chat app.” It was closer to: what if the agents you already use from the terminal could live as persistent workers inside a self-hosted dashboard?

The README describes agents with names and jobs. They can connect to company tools, work inside departments, delegate to each other, and keep running after the human walks away. The repo topics include claude-code, codex, mcp, docker, llm, and self-hosted, which is a pretty clear map of the intended audience.

The important detail is that oto-dock is multi-tenant by design. Many people can collaborate with the same agents, and the project describes four sharing modes that decide how an agent is shared and where its work lands. That is the real product bet: not “one developer, one terminal,” but shared agents with durable context.

As of September 2026, the repository had 107 GitHub stars, was mainly Python, and had just been pushed on September 9. Its README calls it “fair source” and says it runs on your API keys and local models. Treat the license and production-readiness as things to verify before depending on it. The GitHub metadata available in the source signal did not assert a license.

Watch the boundary around the agent process

The most interesting implementation claim is not the 3D dashboard or the “departments” metaphor. It is that each agent can run Claude Code or Codex CLI as a persistent process on your server, inside a kernel sandbox with its own mount and process namespace, with network isolation.

That is the right place to look first. A persistent codex agent is no longer just a command you run, inspect, and close. It is a process with filesystem access, credentials, network choices, logs, and a memory of prior work.

For Codex users, the closest durable artifact is still boring and powerful: AGENTS.md. Put the repo rules there. Keep them small. Make them testable.

For example:

# AGENTS.md

- Do not modify files outside this repository.
- Do not run database migrations unless the task explicitly asks for them.
- Before proposing a patch, run the smallest relevant test command and paste the result.
- Treat MCP tools as read-only unless this file names the write action.
- If network access is unavailable, say so and continue with local evidence.

That file does not replace sandboxing. It gives OpenAI Codex a clear operating contract, while the runtime gives you the hard stop. Good agent systems need both.

The trap is believing “self-hosted” automatically means safe. Self-hosted only tells you where the software runs. It does not tell you whether the agent can read secrets, call a write-enabled MCP server, push to GitHub, or spend money through an API key.

Treat departments as routing, not magic

The “departments” idea is the part that made people curious and skeptical. It is easy to imagine an Engineering agent, Finance agent, Support agent, and Founder agent. It is also easy for that metaphor to become stage dressing if the routing rules are unclear.

The useful version is plain routing. A department should answer: which agent gets this work, which tools can it use, and where does the output go?

A good Engineering department might have one Codex agent with repo access, one documentation agent with read-only docs access, and one reviewer agent that cannot write files. A weak version has three charismatic agents with overlapping permissions and no obvious owner for the final patch.

This is where oto-dock brushes against a broader pattern in local agent ops. Projects like coop Runs Codex and Claude Code in VMs are exploring the same discomfort from another angle: developers want stronger containers around agents before they let those agents run longer.

The trap is using departments to hide uncertainty. If you cannot explain why a task routes to one agent instead of another, the UX is not helping yet. It is just a prettier queue.

Try it without trusting the machine

If you try oto-dock, start with a repo that can be destroyed. The goal is not to prove that agentic company OS software is the future. The goal is to see the control surface clearly: filesystem, network, keys, logs, MCP tools, and review loop.

Here is a safe first experiment you can copy into a scratch repo before connecting anything valuable.

# Safe oto-dock experiment note

Goal:
Let one Codex-backed agent inspect a toy repo and propose a small patch.
The agent must not push, deploy, edit secrets, or call write-enabled tools.

Repo:
- Use a disposable copy of a small service or CLI package.
- Remove real `.env` files, tokens, customer data, and private package credentials.
- Add an AGENTS.md file with repo rules and the verification command.

Runtime boundary:
- Run on a disposable VM, container host, or sandboxed environment.
- Start with network access disabled or heavily limited if the app allows it.
- Mount only the test repo, not your home directory or monorepo root.

MCP boundary:
- First MCP server: read-only only.
- Good first tool: read GitHub issues or docs.
- Bad first tool: write to production Slack, Jira, GitHub, or a database.

Codex instruction:
- Ask for a patch plan before edits.
- Ask for a diff after edits.
- Ask for the exact verification command and result.

Pass condition:
- You can delete the VM and lose nothing important.
- You can review the diff without replaying the whole chat.
- The agent explains what it could not access.

That last line matters. A safe agent should tell you when a boundary blocked it. Silent workarounds are more dangerous than failed tool calls.

For more Codex-specific patterns, keep the official AGENTS.md guidance close and compare it with the Codex CLI workflows topic. The healthiest loop is still simple: clear repo rules, smallest useful task, explicit diff, local verification, human review.

Common questions

Is oto-dock basically Cloudflare OS?

Not exactly; oto-dock is a self-hosted agent platform, while Cloudflare OS is tied to Cloudflare’s estate and product surface. The fair comparison is the “company operating system” metaphor: agents, tools, departments, and workflows in one place. The practical difference to inspect is where code runs, where credentials live, and which systems can be written to.

Is voice mode actually useful for coding agents?

Voice can be useful for dispatching or summarizing work, but it is a weak interface for reviewing patches. oto-dock says agents can have a phone line, which is interesting for quick routing. The caveat is obvious: code changes still need artifacts you can inspect, especially diffs, commands, logs, and test results.

How should work route to the right agent?

Routing should be based on tool access and output ownership, not agent personality. A Codex agent with repo access should receive implementation tasks; a docs agent should receive explanation tasks; a reviewer agent should check diffs without write access. If every agent can do everything, departments become decoration.

Does this rely too much on LLM magic?

It can, if the system treats agents as universal workers instead of constrained processes. The serious version uses boring boundaries: sandboxing, read-only MCP first, scoped API keys, AGENTS.md repo rules, and verification commands. The test is whether a failed or confused agent leaves a reviewable trail instead of a vague success message.

Should I connect a real monorepo first?

No. Start with a disposable repo and one read-only integration. A persistent Codex CLI process on a server changes the risk profile because it may keep state, hold credentials, and run beyond the original prompt. Prove the review loop on a toy repo before mounting anything important.

Best ways to use this research

• Best for: Developers evaluating self-hosted agent platforms that run Claude Code or OpenAI Codex outside a single terminal session.
• Best first artifact: A tiny AGENTS.md file that states filesystem limits, write limits, and the exact verification command the agent must run.
• Best comparison angle: Compare agent platforms by runtime isolation, credential handling, MCP permissions, and reviewable outputs before comparing dashboards.
• Best early warning sign: The demo looks rich, but you cannot tell which agent can write to which system or where the final patch lands.
• Best Codex Workshop takeaway: Codex training should include the local runtime contract, not just prompting technique. The question is what the agent can touch when nobody is watching.

Further reading

• OpenAI Developers — AGENTS.md guide
• OpenAI Developers — Codex CLI docs
• oto-dock — source

One methodology lens

One useful way to read this through our methodology is the Plan step: delegate first-pass decomposition and dependency mapping, review the sequencing and assumptions, and keep ownership of scope and priorities. If that split is still fuzzy, the workflow usually is too.