Run your AI coding agents on your own machine — and drive them from your phone.
The open-source agent control plane. Self-host it, or use the hosted service at omg.dev.
Quick start · Why omg.dev · Agents · Remote access · Security
Running one coding agent in a terminal is fine. Running five is not: they die when you close the laptop, you can't tell which one is stuck waiting on a permission prompt, and you have to be at your desk to answer it.
omg.dev turns a Linux box or macOS workstation into a private control plane for
Claude Code, Codex, OpenCode, Jcode, Cursor, Grok, Pi, and GitHub Copilot. Each
agent runs in a long-lived tmux session that survives disconnects. The
transcript streams to a web UI you can install as a PWA — so you can check on
work, answer prompts, and steer from your phone.
You bring your own agent accounts. omg.dev drives CLIs you already own and authenticate. It does not resell tokens and has no model of its own.
The omg CLI is the supported way to install and manage omg.dev. Use whichever
package manager you already have:
bun install --global @omg-dev/cli && omg computer setupnpm install --global @omg-dev/cli && omg computer setupThe published CLI is currently shebanged
#!/usr/bin/env bun, so annpminstall still needsbunon yourPATHto run. Thebunline above always works; if you install withnpmand seeenv: bun: No such file or directory, install Bun and retry.
Then open http://localhost:8766.
No omg.dev account is needed for this — omg computer setup provisions a purely
local install. The CLI installs Bun, tmux, and git, fetches the latest
release, writes .env, and starts omg.dev as a user service bound to loopback.
It touches nothing outside the install directory — no sudo prompt, no daemons
you did not ask for. The extras below are opt-in. On a fresh Ubuntu/Debian box, add
OMG_INSTALL_SYSTEM_DEPS=1 so it may apt-get the base packages.
The install lands in ~/omg and runs as omg.service (launchd: dev.omg.serve).
Setup downloads a bundle built for your exact OS and CPU with dependencies already installed, so nothing is resolved, compiled, or fetched from npm on your machine. See how installs stay small.
Next: connect a coding agent so you have something to run, then reach it from your phone.
Everything that reaches outside the install directory is off by default and can be turned on later, once omg.dev is already running.
A named local URL. Gives the UI a memorable address without binding the server to any non-loopback interface. Setup takes the cheapest route available:
- If a public DNS name already points at
127.0.0.1—local.omg.dev— it is used as-is. No sudo, no hosts file, nothing for uninstall to undo, and it behaves the same on macOS and Linux. Only trusted when every address it resolves to is loopback. - Otherwise, opt in to an
/etc/hostsentry, which works offline and for any name you like, but is root-owned:
OMG_LOCAL_HOSTNAME=omg.local omg setup # needs sudo: /etc/hosts is root-ownedEither way http://localhost:8766 keeps working.
omg uninstall removes the entry. Note that browsers only grant "secure
context" to https://, localhost, and loopback IPs — so install the PWA
from localhost:8766, not from omg.local, or the service worker will not
register.
Remote access. Installs Tailscale, joins your tailnet, and serves the UI over HTTPS on your tailnet only:
OMG_TAILSCALE_SERVE=1 TS_AUTHKEY=tskey-auth-... omg setupThat gives you a portless https:// URL that works from your phone, with a
publicly valid certificate and nothing exposed to your LAN or the internet.
For development and forks:
git clone https://github.com/BennyKok/omg.dev.git
cd omg.dev
bun install
cp .env.example .env
bun run serveOpen http://localhost:8766. For UI hot reload (proxies /api to the Bun
server): cd web && bun install && bun run dev.
The CLI handles all of this; this list is for the from-source path and for the curious.
- Bun,
tmux,git - At least one coding agent CLI — see below
- Optional: Tailscale for private remote access
- Run agents where your code lives. Sessions execute on your machine, in your repos, with your local CLIs and credentials — not a remote sandbox you have to keep in sync.
- Bring your own accounts. Claude, Codex, OpenCode, Cursor, Grok, Copilot, and Pi all run on subscriptions and keys you already have.
- One UI for every harness. Switch agents and models per session, resume work, answer permission prompts, and manage projects from an installable PWA.
- Survive the lid closing.
tmux-backed sessions keep running when you disconnect, and pick up exactly where they were when you come back. - Keep it private. The server binds to loopback by default and is designed to be exposed through Tailscale, not the public internet.
- Delegate with lineage. omg.dev MCP tools spawn subagents that stay visible in the UI, inherit parent context, and report progress back.
- Show the work. Agents can display verification media, publish updatable HTML dashboards, and post finished results to the Shipped feed.
- Automate repo checks. Optional markdown-defined agents collect git, repo, GitHub, model, or security context and produce scheduled reports.
omg.dev drives agent CLIs that you own and authenticate. Open Settings → Coding agents in the web UI to install one, check its binary path and auth state, and register omg.dev's MCP server with it.
| Agent | Command | Notes |
|---|---|---|
| Claude Code | claude |
Installed by setup |
| OpenAI Codex | codex |
|
| OpenCode | opencode |
|
| Jcode | jcode |
|
| Cursor | cursor-agent |
|
| Grok | grok |
|
| GitHub Copilot | copilot |
Needs Node 22+ |
| Pi | installed on request | OMG_INSTALL_PI=1 omg setup — its provider layer pulls ~115 MB, so it is not shipped by default |
OAuth-based agents need a one-time terminal or browser login. API-key providers
read env vars such as ANTHROPIC_API_KEY or OPENAI_API_KEY from .env. Pi
authenticates via ANTHROPIC_API_KEY or ~/.pi/agent/auth.json.
Settings → Coding agents → Install MCP registers omg.dev MCP with Claude, Codex, OpenCode, Jcode, Grok, and Cursor when those CLIs are present. (Copilot and Pi have no MCP registration surface.) Setup does this automatically for Claude and Codex when they are already installed.
omg.dev binds to loopback and has no authentication of its own — it trusts the network you put it behind. There are two supported ways to reach it remotely:
Tailscale (recommended). The simplest choice if you only open the UI from your own devices:
OMG_TAILSCALE_SERVE=1 omg setupA relay (experimental). For the case Tailscale can't cover — rendering a session from your box on a public web origin:
OMG_RELAY_URL=wss://your-relay.example/connect omg connect ABC123 # outbound only, no inbound portNo relay ships with omg.dev itself; the protocol is generic and any operator can implement it. omg.dev runs one, and the CLI configures the pairing for you:
omg login
omg connect # installs omg.dev if needed, then pairs and connectsFull comparison, the pairing flow, and opt-in session lifecycle events: docs/remote-access.md.
Do not put omg.dev on the public internet without your own auth in front of it. See Security.
omg.dev launches AI agents with shell access on your machine. The control API is unauthenticated by design because it is meant to run on loopback and be reached privately through Tailscale.
Do not expose omg.dev directly to the public internet. Read SECURITY.md before sharing access.
omg.dev is the hosted version, run by the same author — a cloud machine with omg.dev already running, so there's nothing to install and no server to provision. There's a free tier, and it's entirely optional: everything above works forever without an account.
One click gives you a workspace with the omg.dev web UI already up. Workspaces hibernate when idle and wake on the same URL.
Which should I pick? Install locally if you want agents working on the repos and authenticated CLIs already on your machine — that is what omg.dev is for. Use omg.dev to try it in seconds, or when you would rather not run a box at all. A fresh hosted workspace has no agent CLIs signed in, and agents work on repos you clone into it. More detail in deploy/omg.
The omg CLI wraps the whole lifecycle:
omg computer setup # install omg.dev (no omg.dev account needed)
omg computer status # inspect the local install and pairing
omg computer update # update an existing installation
omg computer uninstall # remove omg.dev; preserve sessions and config
omg computer uninstall --purge --yes # also permanently delete local omg.dev dataupdate never installs a missing computer, and uninstall delegates cleanup to
omg.dev instead of guessing which files it owns. Removal stops the service and
deletes its command, MCP registrations, /etc/hosts entry, and release files.
Shared prerequisites such as Bun, Tailscale, tmux, and coding-agent CLIs are
left alone; source checkouts are preserved unless explicitly purged.
The same operations are available from inside an install:
omg setup # update and re-run idempotent provisioning
omg uninstall # remove omg.dev; keep sessions and config for reinstall
omg uninstall --purge --yes # also permanently delete sessions and configomg serve # web UI + control server
omg setup # rerun provisioning/update flow
omg uninstall # remove omg.dev while preserving sessions and config
omg connect <code> # reach this box through a relay (see docs/remote-access.md)
omg mcp # stdio MCP server for omg.dev session tools
omg agents list # list markdown-defined insight agents
omg agents run <name> # run an insight agent
omg subagent models # list runtime sub-agent providers/models
omg subagent create --prompt "..." --agent codex-aisdkFrom a source checkout, use bun run <command> (e.g. bun run serve) — the
surface is identical.
omg mcp talks to the local omg serve API and exposes omg.dev's session tools to
any MCP client. Prefer omg.dev's own subagent tools over a client's generic "spawn
agent" helper so children stay visible in the UI, inherit parent and user
context, and can run on any configured harness.
| Area | Tools |
|---|---|
| Sessions | omg_list_sessions, omg_find_sessions, omg_get_session_tree, omg_get_session_messages, omg_send_session_message, omg_close_session |
| Origin delivery | omg_send_to_origin |
| Presentation | omg_display_image, omg_display_video, omg_publish_artifact, omg_refresh_artifact, omg_delete_artifact, omg_ship |
| Delegation | omg_create_subagent, omg_delegate_to_agent, omg_delegate_design_task, omg_delegate_backend_task, omg_list_subagents, omg_reparent_session |
| Auto agents | omg_list_auto_agents, omg_compose_auto_agent, omg_save_auto_agent, omg_run_auto_agent, omg_delete_auto_agent, omg_list_findings, omg_update_finding |
| Human input | omg_ask_user, omg_input |
| Catalog | omg_capabilities, omg_list_repos, omg_list_models |
Managed sessions launched with an initial task receive a versioned omg.dev runtime contract (when to show media, publish artifacts, ask the user, delegate, or ship). Sessions started on an older contract are marked in the UI so they can be closed and resumed to pick up the current tool catalog.
Subagents may nest up to four levels. Each child sends [subagent progress]
updates and one terminal [subagent complete] / [subagent blocked] /
[subagent failed] message to its parent.
Configuration lives in .env. .env.example documents every
variable inline.
Variables use the OMG_ prefix. These are the ones most people touch:
| Variable | Purpose |
|---|---|
OMG_HOST |
Bind address. Keep 127.0.0.1 unless you know the risk. |
OMG_PORT |
Web UI and API port. Defaults to 8766. |
OMG_LOCAL_HOSTNAME |
Named local URL mapped to loopback, e.g. omg.local. Empty (the default) skips the hosts file. |
OMG_INSTALL_TAILSCALE |
Install and join Tailscale. Off by default; implied by OMG_TAILSCALE_SERVE. |
OMG_REPOS_ROOT |
Directory scanned for git repos. |
ANTHROPIC_API_KEY |
Optional API key for Claude / Pi flows. |
OMG_<AGENT>_PATH |
Override a CLI's binary path (OMG_CLAUDE_PATH, OMG_CODEX_PATH, OMG_OPENCODE_PATH, OMG_JCODE_PATH, OMG_CURSOR_PATH, OMG_PI_PATH, OMG_COPILOT_PATH). |
OMG_RELAY_URL |
Relay WebSocket URL for omg connect. See docs/remote-access.md. |
OMG_INSTALL_CHANNEL |
Install channel: source, release, or container. Usually set by setup/deploy. |
Other groups: agent-specific behaviour (OMG_COPILOT_ALLOW_ALL_TOOLS,
OMG_PI_PROFILE_DIR — see
custom agent profiles), relay event
forwarding (OMG_CONNECT_EVENTS*), and backend tracing
(OMG_TRACE_RETENTION_DAYS, OMG_TRACE_TRANSCRIPT_*).
Backend diagnostics append to data/logs/trace-YYYY-MM-DD.jsonl (API timings,
transcript indexing, live stream stalls, send queue state).
Each release publishes a bundle per platform — omg-linux-x64.tar.gz,
omg-linux-arm64.tar.gz, omg-darwin-x64.tar.gz, omg-darwin-arm64.tar.gz —
with node_modules already installed for that target. Setup downloads the one
matching your machine and skips dependency resolution entirely.
A first install used to pull about 2 GB and resolve the graph locally. It is now 43 MB, and nothing is resolved on your machine. Two things got removed:
Builds the machine cannot execute (667 MB). npm gates platform packages with
the os, cpu, and libc manifest fields. Bun honours os and cpu when
resolving optionalDependencies but not libc, and there is no
bun install --libc to opt out — so every glibc Linux install also downloaded
the musl builds of the Claude agent SDK, both opencode variants, and sharp's
libvips.
Agent runtimes omg.dev does not need (about 1 GB). The Claude, Codex, and
OpenCode SDKs each bundle a private copy of that agent's binary, as a fallback
for machines without the CLI. omg.dev already prefers the CLI on your machine —
pathToClaudeCodeExecutable, codexPathOverride, and a PATH lookup for
opencode — which is the whole premise of bringing your own agent accounts. So
the bundled copies are dropped, and you install the agents you actually want:
# from the UI: Settings → Coding agents → Install
OMG_INSTALL_CLAUDE=1 OMG_INSTALL_OPENCODE=1 omg setup # or headless
OMG_INSTALL_PI=1 omg setup # pi, plus its provider SDKsThat is also how a hosted image ships with agents preinstalled — the same lean
bundle, plus the agents it wants on top. Pi is installed on request too (OMG_INSTALL_PI=1 omg setup): it has no
separately installable binary, and its provider layer pulls ~115 MB.
scripts/prune-modules.ts does both removals at
release time and sweeps the symlinks left behind. Building bundles for other
platforms works because bun install --os --cpu resolves another target's
optional dependencies, so a Linux CI box can produce correct macOS bundles.
scripts/release.sh # neutral bundle + all platforms
LFG_RELEASE_PLATFORMS="linux-x64" scripts/release.sh
LFG_BUNDLE_AGENT_RUNTIMES=1 scripts/release.sh # keep the bundled agent binaries
LFG_SKIP_PLATFORM_BUNDLES=1 scripts/release.sh # neutral bundle onlyThe platform-neutral omg-bundle.tar.gz is still published, and setup falls
back to it (then to the pre-rename lfg-bundle.tar.gz) when no platform bundle
matches — an unusual architecture still installs, it just resolves dependencies
locally the old way.
Every release publishes @omg-dev/protocol, @omg-dev/client, @omg-dev/react,
and @omg-dev/app to npm — the last being the exact full application the
standalone web UI runs. React hosts mount it with their own transport and asset
origin:
npm install @omg-dev/app @omg-dev/clientSee docs/embedding.md.
src/ CLI, server, sessions, tmux, agents, MCP, integrations
web/ React/Vite PWA
agents/ Example markdown-defined insight agents
scripts/setup.sh Installer / provisioning
scripts/ Release, fleet, and smoke helpers
scripts-internal/ Operator-only helpers (gitignored — see CONTRIBUTING.md)
deploy/ Cloud, voice, STT, and ops deployments
docs/ Design notes, agent profiles, README images
Issues and pull requests are welcome. Please read CONTRIBUTING.md and SECURITY.md first.
Upgrading from
lfg? The project was renamed in August 2026 and now lives atgithub.com/BennyKok/omg.dev. GitHub redirects the old URLs. The command isomg; the oldlfgcommand,LFG_*environment variables, and an existing~/lfginstall directory all keep working, and setup never migrates a running install out from under itself.