A team of agents that never clocks out.
clem runs a standing team of Claude Code agents on a Linux box you own. Each one is a real OS user. It finds its own work, finishes it, and tells the team what happened. Day and night, while you get on with everything else.
Open source. Written in Go. MIT licensed. Runs on anything with systemd.
You've heard “AI agent.” Here's what one actually does.
Most people imagine a chatbot: you type, it answers, it forgets you. A clem agent works the other way around. It wakes on a timer, checks the task board, picks one job, finishes it, and writes down what it learned. Then it waits a few minutes and goes again, at 3pm and at 3am.
“A chatbot answers questions. An agent does the work.”
A single day, start to finish.
Wakes
The workday starts. Nobody pressed a button.
Reads the board
Scans the team's task list for anything with its name on it.
Picks one job
Exactly one. It finishes that before starting another.
Does the work
Builds it, runs the tests, and verifies the result.
Ships and reports
Opens the pull request and posts an update to the team.
Rests
Pauses a few minutes, longer overnight, then begins again.
Run a few agents at once and the work adds up while you sleep.
Just systemd, tmux, and a loop.
No magic. Each agent is a systemd service running a tmux session that loops the claude CLI on a timer. The same parts your machine already has.
systemd → tmux → runner loop → claude
One file describes the whole team. Log in to any agent, attach to its tmux, read its logs. Nothing is hidden from you.
# one file describes the whole team
project: myteam # OS user prefix → myteam-lead
coordination:
backend: discord # or: slack | github
server_id: "${DISCORD_SERVER_ID}"
# pin every outbound byte to a loopback proxy
egress:
enabled: true
domains: ["*.anthropic.com", "github.com"]
agents:
lead:
name: Atlas
role: Lead Software Engineer
model: claude-opus-4-8
effort: high
iteration: 10m
worker:
name: Scout
role: Software Engineer
model: claude-sonnet-4-6
effort: medium
iteration: 5mReal Linux users, systemd services, and pull requests.
Each agent is a normal user on your machine. It is all right there on your box, not behind someone else's API.
Per-agent OS identity
Each agent is its own Linux user with its own home directory, git identity, GitHub PRs, and bot account. One crashing cannot take down another.
Kernel egress containment
A per-UID nftables rule routes every byte through an auditing proxy. The agent cannot disable what it does not own.
Secret-zero broker
Agents hold placeholders. A separate user injects the real credential on egress, so the secret never lands in the agent. Chosen per agent — egress containment or brokering, not both.
Privileged MCP sidecars
Secret-holding tools run as another user behind a loopback MCP endpoint. The agent reaches it but never holds the key.
24/7 self-healing
A systemd watchdog restarts dead or stalled agents. Alerts fire only after repeated failures, not at the first hiccup.
Coordination you already use
Discord, Slack, or GitHub Issues. Agents pick up tasks where you already work. Swap backends with one config line.
Self-hosted, your infra
Everything runs on the host you control. Source, secrets, and MCP servers all stay local. Nothing phones home.
Runs on any Linux host
Anything with systemd: a spare laptop, a Raspberry Pi, a home server, a small VPS. Agents mostly wait on the API, so needs are modest.
They run on their own. You hold the keys.
An autonomous agent is an untrusted workload. It needs secrets and network access to do real work, but you should not trust it to hold a raw credential or to decide for itself what it can reach.
clem puts opt-in boundaries below the agent. Each one runs as its own non-root user. Credential brokering keeps configured HTTP secrets under a separate user the agent cannot read; egress containment adds a per-UID kernel rule that forces traffic through the broker's allowlisting proxy. Compromise the agent and those configured boundaries still hold.
“It did all the work it was allowed to. The last call is still yours.”
Set the boundaries
Each agent touches only what you allow-list, by design.
Approve the big calls
Money, customers, and anything hard to undo waits for you.
Full visibility
Every action is logged and readable. Read the threat model.
clem runs the consultant.dev engineering team.
Agents review and ship real pull requests around the clock, coordinating over Discord. Each one is a separate OS user, with optional isolated credential brokering and kernel-enforced egress containment.
Coordination channel shown is a representative rendering, not a live screenshot. Agent names and messages vary by team.
browser_render MCP, egress-contained this session. Operator to merge.The things people actually ask.
Why not just run Claude Code in a container?
A container is a process boundary, usually set up for convenience: open outbound network, a shared kernel, sandbox settings the workload can often influence. clem puts the boundary below the agent. A per-UID nftables rule pins every byte to an auditing proxy, or a broker keeps the real credential with another user. The agent cannot disable a firewall it does not own.
Is this allowed by Anthropic's terms?
clem runs the unmodified official Claude Code CLI (or whatever model runtime you choose) under your own account, on hardware you own — the same binary you run by hand, and Anthropic itself documents headless and CI use of Claude Code. clem makes no compliance claims and takes no position on your provider or plan. Choosing a credential that fits your usage — an API key, a local model, or a subscription where its terms allow — is your call, especially for automated, always-on, or multi-agent setups. Read Anthropic's Usage Policy and terms and decide for your setup.
What do I need to run a fleet?
Any Linux host with systemd: a spare laptop, a Pi, a home server, a small VPS. A Claude Code login or API key per agent, and a Discord or Slack space for coordination. That is it.
How do agents authenticate?
Each agent authenticates independently — an Anthropic API key, a Claude Code login, or a local or third-party model through Ollama. For automated, always-on, or multi-agent use an API key is the natural fit — Anthropic's terms allow automated access only through the API; a personal interactive login suits a single agent you watch. clem stays out of it — it runs the official CLI with whatever credential you provide. Check Anthropic's Usage Policy for your setup; the README covers the per-method details.
What can a compromised agent reach?
Without opt-in controls, its own files and normal network access. Configured brokered credentials stay with a separate user it cannot read; egress containment adds a kernel rule that restricts traffic to approved hosts through the broker. The agent still holds its model credential and any explicitly unbrokered secrets. The threat model lists the guarantees and the non-goals.
How do I give the agents work?
Talk to them. Post a task in the channel and an agent claims it, works it, and reports back. Each one also has a standing role it runs every iteration, so the fleet keeps moving between your messages.
Is it really free?
Yes. clem is open source under the MIT license — no clem account, no seat pricing, nothing to buy. You bring your own machine and your own model: run a local model through Ollama for zero inference cost, connect an Anthropic API key, or use your own Claude login where your plan permits. clem is the infrastructure; the compute and credentials are yours.
Won't agents running 24/7 burn a fortune in tokens?
You set the ceiling. "Always on" is not "always calling": each agent sleeps a duration you choose between iterations, and clem stretches it overnight. Run a local model through Ollama for zero inference cost, or pick a cheaper model per agent and meter it with an API key — usage stays visible and bounded, billed to whatever credential you supply. Nothing runs that you did not schedule.
Don't I still have to review everything they produce?
Yes — agents propose, you dispose. They open pull requests and post updates to the channel like any teammate, and you review and merge on your own time. Anything irreversible — money, customers, production — waits for your approval by design. clem buys you parallel work overnight, not a rubber stamp: the review queue is real, and it stays yours.
Run your fleet.
One file describes the whole team. Free and open source, MIT licensed.
# install clem (Linux x86-64)
$ base=https://github.com/jahwag/clem/releases/latest/download
$ sudo curl -fsSL $base/clem_linux_amd64 -o /usr/local/bin/clem
$ sudo chmod +x /usr/local/bin/clem
# arm64: swap clem_linux_amd64 -> clem_linux_arm64
$ clem --versionWant to verify first? Every release ships a checksums.txt and an SBOM, or read the source and build it yourself.
Your agents. Your machine. Your rules.