[ overgo ] · overcli, for your whole team · alpha
overgo puts overcli’s workers, teams and processes on a server you run. Each worker remembers, holds only the access its job needs, and answers to a manager — and anyone you allow can ask it in Slack.
/data, and read what’s still open before you connect tools.[ why overgo ] · what changes when agents belong to the org
On a laptop, an agent is one person’s helper and forgets when the session ends. On overgo it’s a colleague the whole org can reach — one that remembers, holds only the access its job needs, and answers to a manager.
Every job, every “useful” or “not useful”, every note its manager adds goes into its journal, and it reads the journal before the next job. It learns its tools — the projects, statuses and people its job uses — and reads the org’s handbook. Its Access tab holds its tools, their scope and how much it does alone, and every change has a history you can restore.
Put specialists together and a coordinator plans who does what. Each keeps its own tools, scopes and who-can-ask, so the analyst reads the warehouse, the builder pushes branches, and neither can do the other’s job. The team keeps what it knows — the roadmap, customers, what’s decided — and refreshes it weekly.
Mention @overgo anywhere, DM a worker, sit one in a channel to answer as questions come up, or use the console or Claude. Answers, approvals and files come back in the thread.
See it →controlsSomething a company can sign off onManagers approve what acts — once, for the run, or always. Tools sign in once and are scoped per worker; anything wider is an admin’s call. Budgets per worker, person and org. Every change in a decision log.
See it →yoursYour server, your modelsOne container you run. Anthropic, Bedrock or Vertex — so traffic can stay in your cloud. Open source and free: build it from the repo, or ask for the signed image during the alpha.
See it →[ the basics ] · the overcli you know, for everyone
A worker is a job description with flows, a journal, a manager, a trust level and a budget behind it. On overgo, everyone in the org can ask one — and nobody has to keep a Mac awake for it.
@overgo in any channel, or DM it — it finds the worker that can look it up/worker, /team, /hire and /idea in Slack[ processes ] · teams and people, stage by stage
A process is a series of stages, each a team, a worker, or people who decide. A customer’s problem goes from a channel to a reproduced bug, a fix, a yes from whoever’s on call, a reply the customer can read, and a check a week later — and nobody has to chase it.
Found a flowchart, a swimlane or a slide? From an image drafts the process from it — boxes as stages, decisions as people deciding, rework arrows as send-backs — and saves nothing until you do.
Eleven to start from — bug to fix, customer escalation, security response, postmortems, launch readiness, experiments, onboarding, pricing and more — each says why every stage is there.
A decision can be one person, a group, all of them, or at least N. A send-back or a stop from anyone acts at once. Approvers are matched by Slack id, never by a display name.
Private, a team, certain people, or everyone. People outside a process see only an outline, and an item, its history and its files are shown only to the people in it.
[ from your desktop ]
Workers, teams and processes start on your Mac. When one is ready to share, Publish my setup sends the workspaces, projects and tools you pick — repos as their git remotes, tools as templates, credentials taken out. A tool’s keys travel only if you tick it, only from an admin over https.
overcli, the desktop app →[ databases ] · from overdb
In overdb, Publish to your org’s server… sends a connection without its password, with what workers should know: the tenancy rule, your notes and the map of your code. An admin finishes it on Setup → Databases. Workers query it through overdb’s read-only tool, and each query is logged by worker and run — the SQL and the row count, never the rows. See it in overdb →
[ run it yourself ] · one container
Build the image from the Dockerfile in the repo — Claude Code inside, Codex if you ask for it. Nothing about your org is in it; it all lives on your volume. The signed image is private while overgo is in alpha: ask for read access, log in to ghcr.io with a read:packages token, and pull it instead. A build of your own isn’t signed by our release workflow. Slack is optional: add its two tokens on Setup → Secrets when you want it. Java, Node, Python or Go install from Setup → Toolchains — no rebuild.
# 1 · get the code and say which model to use git clone https://github.com/overcodelions/overcli && cd overcli cp deploy/.env.example deploy/.env # ANTHROPIC_API_KEY=…, or Bedrock / Vertex echo "OVERCLI_VERSION=local" >> deploy/.env # 2 · build the image (add --build-arg INSTALL_CODEX=1 for Codex) docker build -f deploy/Dockerfile -t ghcr.io/overcodelions/overcli-server:local . # 3 · start it, and say who the org is docker compose -f deploy/docker-compose.yml up -d docker compose -f deploy/docker-compose.yml exec overcli \ overcli org init --name "Acme" --admin <your Slack member ID> # 4 · sign in: the log prints a one-time first-admin link docker compose -f deploy/docker-compose.yml logs overcli | grep "first admin"
A laptop, a VM, any host with Docker. Slack connects outbound, so nothing needs a public address.
Read the guide →awsAWSBedrock with no API key on the box, /data on a durable disk with snapshots, HTTPS from inside your VPC.
Read the guide →google cloudGoogle CloudVertex through the server’s identity, a durable disk, and HTTPS in front from inside your network.
Read the guide →Alpha, and what’s still open. Workers run as a user of their own — on in the compose file by default — so they can’t read the server’s secrets, the tool gateway’s key or people’s tokens, and command tools’ tokens are sealed in the server. Two things a worker can still reach: the model’s credentials its CLI needs, and on EC2 or Compute Engine, the instance’s cloud identity — keep that role to Bedrock or Vertex and the secrets prefix. The security page covers the rest.
[ faq ]
No. overgo is the org server for overcli, and you run it: one container, on a laptop, a VM, Docker, Fargate or Cloud Run. Nothing about your org is in the image — workers, journals, tokens and the rules all live on your own /data volume. There is no overgo account, and nothing calls home except an optional daily check for a newer release (OVERCLI_UPDATE_CHECK=0 turns it off).
Nothing from us. It’s in the overcli repo under Apache 2.0, with no seats and no paid tier. You pay for what the workers use: a model key, or Bedrock or Vertex through your cloud account, and every worker, person and the org has a budget, so scheduled work stops at the limit.
Same engine, different front door. overcli is the desktop app: one person, on their Mac, approving in the app. overgo runs the same workers, teams, flows and processes on a server, so everyone in the org can ask in Slack, the console or Claude, and each worker’s manager approves from wherever they are. Build in the app; publish to the org when it’s ready to share.
It’s an alpha. It works end to end and it changes quickly between versions — back up /data. In the desktop app, org features stay off until you turn on Settings → Labs → Org workers.
Safer than it was, and still alpha. Workers run as a user of their own, so they can’t read the server’s secrets, the tool gateway’s key or people’s tokens, and command tools’ tokens are sealed in the server; every file read is kept to a run’s own folders. What a worker can still reach: the model’s credentials its CLI needs, and on EC2 or Compute Engine the instance’s cloud identity, so keep that role narrow. Trust levels, narrowed commands, budgets, tool scopes, the tool gateway and the decision log are all on the security page.
No. Slack is optional: without it, people use the web console, or Claude Code, Claude Desktop and Codex through MCP. With it, Slack connects outbound over Socket Mode, so the server needs no public address.
Not yet. Slack is the chat front door today. Without Slack, people use the web console, or Claude Code, Claude Desktop and Codex through MCP.
Never. Workers run no git: the model edits files in its own worktree, and the server commits and pushes an overcli/<change> branch once the repo’s tests pass, then opens its pull request on GitHub or Bitbucket — as a draft by default, for review, or as a link only. It reads the repo’s own CI, and a red build goes back to the same worker to fix on the same branch; after a few rounds, its manager hears. A worker that asks first pushes nothing without its manager’s yes, and people review and merge.
[ family ] · over your tools, not instead of them
One window over your agent CLIs — then put them in a loop.
overgit →A better git client — and one ticket across many repos.
overdb →Every environment at once — and branches of your data.
overcli for your whole team — on your own server.