HumanLayer
Run coding agents on your own machines and steer them from one place — tasks, sessions, plans, and reviews.
- Source repo
- humanlayer/humanlayer
- Stars
- ★ 12k
- Last updated
- today
- License
- Apache-2.0
- Primary language
- TypeScript
- FA score
- 49/100 · Major gaps
At a glance
- How it runs
- Works with
- Portable with changesCodex · Claude Code
- Cost
- Free tier plus a paid hosted plan
- Setup effort
- Medium · a few setup steps
- You'll need
- Typical use
- Engineering teams running multiple Claude Code sessions in parallel who want to review and steer them from one console instead of juggling terminals
- Not a fit if
- Teams wanting a turnkey hosted-only product — self-hosting guides are still in progress
- Teams not using Claude Code, Codex, OpenCode, or Pi, since session mirroring depends on those plugins
- Source review
- 49/100 · Major gaps
What does this agent do, and when should you use it?
HumanLayer is an open-source agent orchestration platform that runs coding agents (Claude Code, Codex, OpenCode, Pi) on your machines and lets your team steer them from one place. The repository is a Turborepo monorepo on Bun, containing the riptide-ui web app, two macOS desktop shells (Electron and Tauri), the riptide-daemon that runs agent sessions on each host, the humanlayer CLI, and an oRPC + Hono API. The daemon executes sessions while Electric syncs Postgres to clients, keeping tasks, sessions, plans, and reviews in sync across desktop, web, and daemons. Plugins such as riptide-claude-code-plugin, riptide-opencode-plugin, and riptide-pi-extension mirror external agent sessions into HumanLayer. HumanLayer Cloud runs this same code, and the repo can also be built and self-hosted from source.
Runs coding agent sessions (Claude Code, Codex, OpenCode, Pi) on each host via riptide-daemon, which ships with the humanlayer CLI. riptide-ui provides web and desktop (Electron/Tauri) interfaces where teams view and steer tasks, sessions, plans, and reviews from one place. riptide-api (oRPC + Hono) handles the backend, and riptide-electric-proxy fronts Electric to sync Postgres data to clients; sessions are mirrored in via riptide-claude-code-plugin, riptide-opencode-plugin, and riptide-pi-extension. riptide-cloud provides the admin app (organizations, invites, settings, install page), while AWS Lambda jobs like updater-server and stale-daemon-sweeper handle maintenance. The repo also ships Research-Plan-Implement skills (riptide-rpi-claude-plugin), a Linear CLI, and devstack for running the full stack locally.
- Engineering teams running multiple Claude Code sessions in parallel who want to review and steer them from one console instead of juggling terminals
- Developers working across several machines who need task and session state synced between a desktop app, web app, and per-host daemons
- Teams already using Codex, OpenCode, or Pi who want their sessions mirrored and centrally managed via the mirroring plugins
- Organizations that must self-host and keep data on their own machines — a from-source build keeps Sentry, PostHog, and WorkOS disabled by default
- Teams following a Research-Plan-Implement workflow with Linear issue tracking via linear-cli
How do you install or deploy this agent?
Prerequisites: [Bun](https://bun.sh) and Docker; building apps/riptide-native also needs Rust.
bun install
cp .env.example .env
bun --bun run typecheck
bun run test.env.example lists configuration for Sentry, PostHog, and the WorkOS client ID; in a from-source build these stay off when unset.
How do you use this agent?
Run the full local stack:
bun --bun run devstack helpThis command explains how to run the whole stack locally per worktree via devstack (API, database sync proxy, and more). Daily workflow: deploy riptide-daemon on each host (the humanlayer CLI ships the daemon), then create tasks, start sessions, write plans, and do reviews from the desktop or web app; use riptide-claude-code-plugin, riptide-opencode-plugin, or riptide-pi-extension to mirror external agent sessions. CONTRIBUTING.md lists every check a pull request must pass.
What are this agent's strengths and limitations?
- Unifies multiple coding agents (Claude Code, Codex, OpenCode, Pi) running on your own machines into one console for review and steering
- Ships both Electron and Tauri macOS desktop apps, a web app, and a CLI, with data synced across them via Electric + Postgres
- A from-source build sends nothing externally — Sentry, PostHog, and WorkOS are controlled by environment variables
- Apache-2.0 licensed, and HumanLayer Cloud runs the same code you can self-host
- Self-hosting guides are still in progress; a source deployment involves Bun, Docker, a Postgres/Electric sync chain, and multiple Lambda jobs
- The Docker Compose self-hosting starter uses default/simple passwords that must be changed before deployment
- Desktop apps are macOS-only (riptide-electron, riptide-native) — no Linux or Windows desktop clients
- Building apps/riptide-native additionally requires a Rust toolchain, and the large monorepo needs the full devstack for local development
How does this agent compare with similar options?
The repo's topics list claude-code, codex, opencode, and amp, indicating HumanLayer is positioned as an orchestration and human-oversight layer on top of these coding agents rather than a competing agent.
Key facts side by side with the most closely related agents.
| Agent | Source review | Form / cost | Stars | Updated | Language | Full support on |
|---|---|---|---|---|---|---|
| HumanLayer This agent | 49 · Major gaps | Self-hosted serviceFreemium | ★ 12k | today | TypeScript | Codex · Claude Code |
| Deep Research Skills | 43 · Major gaps | Agent plugin / skillFree + model costs | ★ 2.4k | 2mo ago | Python | Codex · Claude Code |
| PRO-LONG | 57 · Major gaps | CLIFree | ★ 459 | 2mo ago | Python | Codex · Claude Code |
| MonoCode | 56 · Major gaps | Desktop appFree | ★ 3.4k | today | TypeScript | Codex · Claude Code |
How does FollowAgents rate this agent?
Why each dimension lost points
Evidence shows telemetry (Sentry/PostHog/WorkOS) is off by default via env vars and builds send nothing out — good for data-flow transparency and sensitive-data handling; a socket security scanner is present in devDependencies; Docker Compose default passwords are explicitly warned about. But the permission model (daemon running agent sessions, permissionsMode: 'bypass' seen in automation-run tests), user-confirmation mechanisms, and rollback are undocumented in the provided files, hence low scores. Publisher identity is unverified and attribution is only partially visible via SECURITY.md's mention of HumanLayer Cloud.
Three provided CLI test suites cover token-refresh races, option validation, and error formatting, with actionable failure messages (e.g. `humanlayer login`). However, only tests are shown — not the implementations under test or CI results — and dependency availability (Bun/Docker/Rust) is asserted, not demonstrated.
README clearly targets teams running coding agents on their own hosts, with stated requirements (Bun, Docker, Rust, Node>=24). But the automation CLI defaults to permissionsMode 'bypass' without documented boundaries or risk framing, and trigger precision / capability boundaries lack documentation.
Information architecture is a clear strength: README maps every app/package in the monorepo; Apache-2.0 full text plus NOTICE for vendored MIT folders; concrete install steps; known limitations flagged (self-hosting in progress, Compose default passwords). No CHANGELOG or versioning policy, examples are command-only, and maintenance responsibility/governance files (CONTRIBUTING referenced but not provided) are absent.
The value proposition (central steering of multi-agent sessions) is clear, but the provided files cannot demonstrate output usability, marginal value over alternatives, or cost/benefit; the bypass permission default in automation runs implies unattended-run risks that are not documented.
README claims are partially corroborated by package.json (socket scanner, env-controlled telemetry) and facts are mostly separable from inference; but key claims ('sends nothing to us', passing tests, daemon behavior) cannot be traced to implementations in the supplied files, so corroboration is weak.
- The automation run path defaults to permissionsMode: 'bypass', meaning unattended agents may skip permission prompts; audit the daemon and automation command permission boundaries before deployment.
- The Docker Compose self-hosting starter uses default/simple passwords that must be changed before deploying.
- Publisher identity is unverified; audit the lockfile and supply-chain integrity yourself (bun.lock etc. were outside the reviewed evidence).
- Self-hosting guides are in progress; production deployments lack complete documentation.
- This is a static source review; no tests were executed and no runtime behavior was verified.