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. The awkward middle space between local coding agents, cloud sessions, API keys, and collaboration. 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 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.
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.
Watch for 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.
Don't use 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 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.