Autonomous agents,
contained by the kernel.
clem runs a team of Claude Code agents 24/7 on any Linux host you own. Each agent is a real OS user. Its secrets and network access are controlled by the kernel and a separate user, not by the agent itself.
# install the latest release (Linux x86-64)
$ curl -fsSL https://github.com/jahwag/clem/releases/latest/download/clem_linux_amd64 \
-o /usr/local/bin/clem && chmod +x /usr/local/bin/clem
# scaffold config, provision the OS users, start the fleet
$ clem init && clem vault init
$ sudo clem provision && sudo clem login && sudo clem upOpen source · Go · MIT licensed · runs on any host with systemd
An autonomous agent is an untrusted workload.
Agents need secrets and network access to do real work. But you can't trust an autonomous agent to hold a raw credential, or to decide for itself what it's allowed to reach.
Telling the agent "don't leak this" is a policy, not containment. If enforcement depends on the agent cooperating, it isn't enforcement.
Contain it at the OS layer.
clem puts the boundary below the agent. Each one runs as its own non-root Linux user; secrets and egress are enforced by the kernel and a separate user the agent can't read or override.
- A non-root agent cannot disable a firewall it doesn't own.
- A brokered agent holds placeholders, never the real secret.
- Enforcement lives in the OS layer, below the agent.
Every credential takes one disposition.
Four ways to contain what an agent can hold and where it can reach. Each is enforced by the kernel and a separate user, never by the agent.
Per-UID nftables rule
A per-UID nftables rule forces all traffic through pipelock, an auditing loopback proxy. A non-root agent can't disable a firewall it doesn't own.
The agent holds a placeholder
The agent carries only a placeholder; a separate user (agent-vault) injects the real credential on egress. The agent never sees the secret. cat ~/.env yields nothing usable for the brokered keys.
Key stays in another user
For credentials the broker can't reach (non-HTTP protocols, or tools that need the raw key in-process), the tool runs as a separate user behind a loopback MCP endpoint. The agent calls it but never holds the key.
Not present at all
Unused secrets simply aren't present. No placeholder, no broker, nothing to leak.
Containment is enforced below the agent. The real credential lives in a vault owned by a separate user the agent cannot read, and egress is pinned by a kernel rule the agent cannot rewrite. Compromise the agent and the boundary still holds.
Just systemd, tmux, and a loop.
Each agent is a systemd service running a tmux session that loops claude on a timer. Parts your host already has: systemd → tmux → runner loop → claude.
# clem.yaml: one file describes the whole team
project: myteam # OS user prefix → myteam-lead
coordination:
backend: discord # or: slack | github
server_id: "${DISCORD_SERVER_ID}"
channels:
tasks: "${DISCORD_TASKS_CHANNEL}"
alerts: "${DISCORD_ALERTS_CHANNEL}"
# egress disposition: kernel-pin all traffic to a loopback proxy
egress:
enabled: true
domains: ["*.anthropic.com", "github.com"]
agents:
lead: # → OS user myteam-lead
name: Atlas
role: Lead Software Engineer
model: claude-sonnet-4-6
effort: high # extended-thinking budget per session
iteration: 10m
worker:
name: Scout
role: Software Engineer
model: claude-sonnet-4-6
effort: medium
iteration: 5m
# broker + sidecar dispositions: see samples/secure-fleet/Real Linux users, real systemd, real PRs.
Each agent is a normal Linux user. Log in, attach to its tmux, read its logs. It's all right there on your box.
Per-agent OS identity
Each agent is its own Linux user, with its own home dir, git identity, GitHub PRs, and bot account. One agent crashing can't take down another.
Kernel egress containment
A per-UID nftables rule routes every byte through an auditing proxy. The agent can't disable what it doesn't own.
Secret-zero broker
Agents hold placeholders; a separate user injects real credentials on egress. The secret never lands in the agent.
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.
Multi-backend coordination
Discord, Slack, or GitHub Issues — agents pick up tasks where you already work. Swap backends with one config knob.
Runs on any Linux host
Anything with systemd: a laptop, a Raspberry Pi, a home server, a small VPS.
Self-hosted, your infra
Everything runs on the host you control. Source, secrets, and MCP servers all stay local.
clem runs the consultant.dev engineering team.
Agents review and ship real pull requests around the clock, coordinating over a Discord channel. Each one is a separate OS user, contained below the agent by the OS and a separate user.
browser_render MCP, egress-contained this session. Operator to merge.The questions people actually ask.
Why not just run Claude Code in a container?
A container is a process boundary, and it's usually configured for convenience: blanket outbound
network, a shared kernel, and sandbox settings the workload can often influence. clem puts the
boundary below the agent instead. You pick a
disposition per agent: a per-UID nftables rule that pins every outbound byte to an
auditing proxy, or a secret-zero broker where the real credentials live with a
different OS user. Either way the
enforcement is owned by root or another user — the agent can't disable a firewall it doesn't own or
read another user's files, and there's no --dangerously-skip flag for it to talk
itself into.
clem also provisions the half containers don't: per-agent git and GitHub identity, Discord/Slack coordination, and a watchdog. The full comparison is in the threat model.
Is running Claude Code this way allowed by Anthropic's terms?
clem runs the unmodified official Claude Code CLI under your own account, on hardware you own — it loops the same binary you'd run by hand, and Anthropic itself ships headless and CI integrations of Claude Code.
clem makes no compliance claims either way. Read Anthropic's Usage Policy and the Consumer / Commercial Terms and decide for your own setup.
What do I need to run a fleet?
Any Linux host with systemd: a spare laptop, a Raspberry Pi, a home server, a small VPS.
Agents spend most of their time waiting on the model API, so CPU and RAM needs are modest.
Beyond that: a Claude Code login or API key per agent (clem login walks each one
through it), and a Discord or Slack space for coordination.
What can a compromised agent actually reach?
Its own home directory and whatever you allow-listed — by design. An egress-contained agent has every outbound byte pinned to an auditing proxy by a kernel rule it can't rewrite; a brokered agent holds only placeholders, with the real credentials kept by a separate user it can't read.
Just as important is what clem does not protect against — the threat model states the guarantees and the explicit non-goals.
How do I give the agents work?
Talk to them. Post a task in the coordination channel and an agent claims it, works it, and reports back. Each agent also has a standing role prompt it executes every iteration, so the fleet keeps making progress between your messages.
Run your fleet.
One config file describes the whole team. Free and open source · MIT licensed.
$ curl -fsSL https://github.com/jahwag/clem/releases/latest/download/clem_linux_amd64 \
-o /usr/local/bin/clem && chmod +x /usr/local/bin/clemRuns on any Linux host with systemd.