Turn CLI agents into a working team.
Clem turns the CLI agents you choose into an owner-directed team. Assign work through Discord, Slack, or GitHub, preserve context with ZestMem, coordinate agents with AgentBus, and supervise the fleet from your own Linux host.
You assign the issues and keep the judgment. Agents persist on assigned work and report what happened.
Open source · Go · MIT licensed · Runs on Linux with systemd
One stack for running a CLI agent team.
Clem runs the team and tracks its work through Discord, Slack, or GitHub. AgentBus carries agent-to-agent messages, ZestMem preserves operator-curated durable memory, and MCP servers connect agents to configured tools and services.
flowchart LR owner["Owner
priorities, roles, approvals"] issues["Clem issue tracking
Work surfaces: Discord · Slack · GitHub"] subgraph core["Clem core"] direction TB orchestrator["Agent orchestrator
schedule · lifecycle · supervise · coordinate"] bootstrapper["Agent bootstrapper
OS users · identity · config · CLI runtimes"] enablement["Agent environment
prompts · skills · best practices
context compression · output compression"] operations["Fleet supervision
schedules · watchdog · logs · terminals
runtime usage signals"] security["Security and isolation
vault and credential brokering · egress
permissions · resource limits"] agents["CLI agent team
Claude Code · Codex · other CLIs"] orchestrator --> bootstrapper bootstrapper --> agents orchestrator --> operations bootstrapper --> security enablement -. "installs configuration" .-> agents operations -. "starts and supervises" .-> agents security -. "confines and protects" .-> agents end subgraph companions["Companion services"] agentbus["AgentBus
agent communication bus"] zestmem["ZestMem
durable agent memory"] end mcp["MCP servers and sidecars
tools · data · internal services"] systems["Repositories and systems
GitHub · browsers · APIs · databases"] owner -->|"defines the team"| orchestrator owner <-->|"assigns and reviews"| issues issues <-->|"claim · update · complete"| agents agents <-->|"messages"| agentbus agents <-->|"recall · remember"| zestmem agents <-->|"tool calls"| mcp mcp <-->|"scoped access"| systems classDef person fill:#C2532B,color:#fff,stroke:#A8431F,stroke-width:2px classDef coreNode fill:#F6F0E2,color:#1E1B17,stroke:#C2532B,stroke-width:2px classDef companion fill:#E2D5B8,color:#1E1B17,stroke:#3B5A3A,stroke-width:2px classDef external fill:#fffaf0,color:#1E1B17,stroke:#655d4d,stroke-width:1.5px class owner person class orchestrator,bootstrapper,enablement,operations,security,agents coreNode class agentbus,zestmem companion class issues,mcp,systems external
AgentBus and ZestMem are optional, independently deployable companion services. Clem uses GitHub, Discord, or Slack as the human-facing work surface.
From assigned issue to reviewed artifact.
On the schedule you set, each agent checks its assigned issues, continues one item, verifies its work, and reports progress. When no assigned work is ready, it waits.
“Assigned work stays visible from claim to handoff.”
One scheduled iteration, start to finish.
Checks assigned issues
Reads the configured work surface and operator corrections.
Continues one item
Resumes an active issue or claims one assigned to its role.
Implements
Produces one concrete artifact without opening unrelated work.
Verifies
Runs the relevant tests and checks the result.
Reports status
Opens or updates the pull request and reports to the team.
Waits
Ends the iteration and waits for the next scheduled run.
Each iteration advances owner-assigned work or waits when nothing is ready.
Built from inspectable Linux services.
Each agent runs in a systemd-managed tmux session, with Clem generating and supervising the surrounding configuration for your chosen CLI agent.
systemd → tmux → runner loop → CLI agent
A single Clem configuration defines agents, roles, runtimes, schedules, and integrations. Inspect the generated services, attach to an agent's tmux session, or read its logs from the host.
# one configuration defines the team
project: myteam # OS user prefix → myteam-lead
coordination:
backend: discord # or: slack | github
server_id: "${DISCORD_SERVER_ID}"
# route contained agents through the configured proxy
egress:
enabled: true
domains: ["api.openai.com", "*.anthropic.com", "github.com"]
agents:
lead:
name: Atlas
role: Lead Software Engineer
runtime: codex
model: gpt-5.4
effort: high
iteration: 10m
worker:
name: Scout
role: Software Engineer
runtime: claude-code
model: claude-sonnet-4-6
effort: medium
iteration: 5mA complete operating layer for CLI agents.
Agents run as inspectable services on infrastructure you control. Clem itself does not require a hosted control plane; agents still connect to the model providers and services you configure.
Per-agent OS identity
Each agent has its own Linux user, home directory, Git identity, runtime credentials, and work-surface identity. Optional resource limits reduce cross-agent interference.
Kernel egress containment
When containment is enabled, per-user nftables rules route agent traffic through the configured proxy. The rules run outside the agent user's permissions.
Secret-zero broker
Agents hold placeholders. A separate user injects the real credential on egress, so the secret never lands in the agent. Choose either egress containment or brokering for each agent, not both.
Privileged MCP sidecars
Secret-holding tools run as another user behind a loopback MCP endpoint, so the agent does not need the credential.
Watchdog recovery
A systemd watchdog restarts agents that exit or stop making progress. Alerts fire after repeated failures.
Issue tracking where you work
Clem tracks assigned agent work through Discord, Slack, or GitHub. Agents claim issues, report status, and record completion on the configured surface.
No hosted Clem control plane
Clem runs on the host you control. Agents connect to the model providers, work surfaces, MCP servers, and other services you configure.
Runs on supported Linux hosts
Run Clem on an x86-64 or arm64 Linux host with systemd, from a spare machine to a VPS.
Configure the boundaries. Inspect the result.
Treat every agent as an untrusted workload. It may need credentials and network access, but it should receive only the access required for its assigned role.
Clem provides opt-in controls outside the agent user. Credential brokering keeps configured HTTP secrets under a separate user; egress containment routes traffic through the configured allowlisting proxy. The threat model documents the guarantees and non-goals.
“Agents execute within configured boundaries. Operators retain sensitive decisions.”
Set the boundaries
Configure per-agent egress, permissions, credentials, and resource limits.
Reserve sensitive actions
Team instructions should reserve money, customer, production, and other sensitive decisions for an operator.
Inspect the fleet
Read service logs, agent output, current status, and repeated-failure alerts from the host.
Clem runs the consultant.dev engineering team.
At consultant.dev, Clem agents work assigned engineering issues and report through Discord. Each runs as a separate OS user, with optional credential brokering and egress containment.
The coordination channel 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 a CLI agent in a container?
A container provides a process boundary, but it does not provision agent identity, issue tracking, scheduled iteration, watchdog recovery, skills, or runtime-specific configuration. When enabled, Clem also adds per-user egress controls or credential brokering outside the agent user.
Which CLI runtimes does Clem support?
Clem supports Claude Code, Codex, and OpenCode. Each agent can use its own runtime, model, provider, effort level, credentials, and schedule.
What do I need to run a fleet?
Any Linux host with systemd, a supported CLI runtime with its required credentials, and a configured Discord, Slack, or GitHub work surface.
Which provider terms apply?
Provider terms differ by runtime, credential type, account, and usage pattern. Review the terms for every CLI and account you configure, especially for scheduled or multi-agent use. Clem does not make compliance claims for a provider or plan.
What can a compromised agent reach?
Without opt-in controls, an agent has access to its own files and the host's normal network path. With credential brokering, configured secrets remain under a separate user. With egress containment, per-user rules restrict traffic through the configured proxy. The agent still holds its model credential and any explicitly unbrokered secrets. The threat model lists the guarantees and non-goals.
How do I give the agents work?
Assign an issue through the configured Discord, Slack, or GitHub surface. The agent claims it, works it across scheduled iterations, reports status, and records completion or a blocker.
Is it really free?
Yes. Clem is open source under the MIT license. There is no Clem account or seat pricing. You provide the host, runtime, model access, and any companion services. A local model avoids a per-token provider bill but still uses your hardware.
How do I control model usage?
Set active and overnight iteration schedules, choose the model and effort level per agent, use cheaper subagent models where supported, and monitor usage through the configured runtime. Clem does not impose a provider budget ceiling.
Don't I still have to review everything they produce?
Yes. Agents produce artifacts and report status; your team reviews and approves the result. Team instructions should reserve sensitive actions for an operator, and technical controls should enforce boundaries where possible.
Install Clem.
A single configuration defines agents, roles, runtimes, schedules, and integrations. Free and open source under the MIT license.
# 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.
Owner-directed agent teams, running on your infrastructure.