agentglass
Run, watch and approve every coding agent on your machine from one window — live cost, tokens, tool calls and a hold on anything dangerous.
- Source repo
- SirAllap/agentglass
- Stars
- ★ 344
- Last updated
- today
- License
- MIT
- Primary language
- TypeScript
- FA score
- 72/100 · Some gaps
At a glance
- How it runs
- Works with
- Portable with changesCodex · Claude CodeOpenAI API · Claude API (Partial support)
- Cost
- Free software; you pay for model usage
- Setup effort
- Medium · a few setup steps
- You'll need
- Typical use
- A solo developer running several Claude Code and Codex sessions who wants terminals, PRs, diffs and permission prompts in one window
- Not a fit if
- Users unwilling to install tmux and Python 3 locally
- Teams that need a hosted, zero-config cloud service
- macOS users who require a signed and notarized build
- Source review
- 72/100 · Some gaps
What does this agent do, and when should you use it?
agentglass is a desktop workspace that runs on your own machine: an Electron shell around a Bun/SQLite server and a React/Vite UI, bundling the terminals, pull requests, diffs, browser and approvals of Claude Code, Codex, Gemini CLI and OpenCode into a single window. It does not proxy agents; it attaches to sessions already open in tmux, or cuts a worktree and branch and runs the same CLI inside it. The Lantern view sorts what needs you: red for an agent stopped on a permission gate, amber for one waiting for input, with gated tool calls held on a disk-backed queue until you approve them from the desk or the phone. An orchestrator agent seats itself per project and hands work to workers under a policy set in Settings, with a lock that keeps pushes and merges out of their reach. Everything is stored in a local SQLite file with no account, no cloud and no telemetry; the only two outbound paths, a self-configured webhook and the Explain button, are opt-in and off by default.
Installing the desktop build starts an embedded server, and the UI is reachable at http://localhost:4000. It attaches to existing tmux sessions (tmux windows become tabs) and can turn a task or GitHub issue into a worktree, a branch and a running agent, several at once without colliding; an orchestrator agent then delegates to workers under the Settings policy (which engine sits in the chair, which work, what a worker may touch, and quota fallback rules). Lantern aggregates pending items, and gated tool calls enter a persistent on-disk approval queue you answer from the desk or a paired Android app. A diff viewer groups word-level changes by agent and worktree, while a source-control panel stages hunks, commits, branches, stashes and resolves conflicts; a pull-request panel shows checks, conversation and files with an inline review composer. The built-in browser panel is driven by agents through a CLI and an MCP server using your existing logins. Further panels cover Docker containers and logs, listening ports and their owning checkout, a file browser, CPU/memory, and per-session cost and time. A stdlib-only Python hook forwarder (hooks/install_hooks.py) makes Claude Code report to it.
- A solo developer running several Claude Code and Codex sessions who wants terminals, PRs, diffs and permission prompts in one window
- Someone who wants to approve a gated agent action or check a stuck session from their phone after hours
- A team that turns each GitHub issue into a worktree and dispatches it to several agents in parallel
- Users who want to see actual token spend and time distribution per agent and per session
- Engineers who want agents to drive a pre-authenticated browser panel for web tasks
- People who want Docker containers, listening ports and resource use visible without a separate monitor
How do you install or deploy this agent?
Download the build for your platform from Releases: .AppImage / .deb for Linux, .dmg for macOS (Apple silicon and Intel), a signed .apk for Android. The macOS build is unsigned, so on first launch run once:
xattr -dr com.apple.quarantine /Applications/agentglass.appOr run from source:
git clone https://github.com/SirAllap/agentglass && cd agentglass
bun install
AGENTGLASS_STATE_DIR=~/.local/state/agentglass-dev bun run dev # http://localhost:4000, its own database
python3 hooks/install_hooks.py # so Claude Code reports to itRequired: git, the Claude Code CLI, and Python 3. Per feature: tmux (live panes, tmux windows as tabs, theme sync), the GitHub CLI (pull-requests panel, and logged in), Docker (containers, images, volumes, logs). Settings ▸ Requirements checks them all. Full details in docs/INSTALL.md.
How do you use this agent?
- Launch the desktop app or
bun run dev, then open http://localhost:4000. - Check Settings ▸ Requirements for dependencies, and set the orchestration policy (which engine orchestrates, which do the work, what workers may touch).
- Existing tmux sessions attach automatically; you can also create a worktree and branch from a task or GitHub issue and start an agent there.
- Work the Lantern: red items are stopped on a permission gate, amber items wait for your input; allow or deny each gated tool call.
- Use the diff viewer and source-control panel to stage hunks, commit, branch and stash; use the pull-request panel for checks, files and inline review.
- To give agents a browser, drive the built-in browser panel through its CLI or MCP server.
- Pair the Android app by scanning a code; then reach terminal panes, approvals, pull requests and a checkout's changes at the scope you grant.
- If agents should report to it, run
python3 hooks/install_hooks.py.
What are this agent's strengths and limitations?
- One window replaces the terminal-per-agent, browser-tab-per-PR and chat-window-for-prompts sprawl
- Gated tool calls are held on a disk-backed queue answerable from desk or phone, so a crash cannot silently allow them
- Attaches to existing tmux sessions and runs the native CLIs rather than proxying them, so agents survive closing the app
- Data lives in a local SQLite file with no account, cloud or telemetry, and every outbound switch is documented
- Covers Claude Code, Codex, Gemini CLI and OpenCode, and can point Claude Code at Kimi, OpenAI, Gemini or Bedrock
- Expects git, the Claude Code CLI and Python 3 on the machine, with tmux, GitHub CLI and Docker needed per feature, so first setup is not trivial
- The macOS build is unsigned and un-notarized, requiring an xattr command to get past Gatekeeper
- The Windows build passes CI but has not been verified on real hardware
- The orchestrator lock is a policy-level guard rather than a sandbox; workers run with your own identity
- Desktop-embedded server design targets a single machine, not multi-host or hosted shared use
How does this agent compare with similar options?
Key facts side by side with the most closely related agents.
| Agent | Source review | Form / cost | Stars | Updated | Language | Full support on |
|---|---|---|---|---|---|---|
| agentglass This agent | 72 · Some gaps | Desktop appFree + model costs | ★ 344 | today | TypeScript | Codex · Claude Code |
| Munder Difflin – Multi-Agent Office Floor | 43 · Major gaps | Desktop appFree + model costs | ★ 9.1k | today | TypeScript | ChatGPT · Codex · Claude Code |
| PI-Desktop | 68 · Some gaps | Desktop appFree + model costs | ★ 7.4k | today | TypeScript | OpenAI API · Claude API |
| CLI Agent Orchestrator | 65 · Some gaps | CLIFree + model costs | ★ 1.5k | today | Python | Codex · Claude Code |
How does FollowAgents rate this agent?
Why each dimension lost points
Evidence shows extensive explicit design around the permission surface: default binding to 127.0.0.1, desktop minting 0600 tokens by default, per-capability switches such as AGENTGLASS_TERMINAL_DISABLED / GIT_WRITE_DISABLED / DOCKER_WRITE_DISABLED, paired devices graded read/answer/full with deny by default, and the self-update route restricted to the desktop shell origin with signed-tag verification. But the deductions are explicit: SECURITY.md itself states the token does not separate the user from their own agent, a hand-started tokenless server is open to any local uid, the gate is fail-open by default, the paired key travels over plain HTTP, and an active man-in-the-middle risk is acknowledged; these are weaknesses written in the files, so least_privilege and sensitive_data_handling get only 2. data_flow_transparency gets 3 because CONFIG.md lists each outbound call (Anthropic usage, GitHub releases, githubstatus, gh CLI, Explain, webhook, LiteLLM pricing) and its switch. dependency_security is only 1: only CodeQL/Dependabot claims, with no lockfile contents or dependency audit evidence. rollback gets 2: setup:undo, settings backup, device revocation and token rotation exist, but rollback of already-written database or already-pushed changes is not described. source_attribution gets 2: README and LICENSE state the author and MIT, NOTICE.md mentions third-party icons, but the publisher identity is unverified by FollowAgents, which is unknown rather than suspicious.
self_consistency is 2: docs and code paths are broadly consistent, but behaviors acknowledged in SECURITY.md such as gate self-release and the token not separating user from agent are in tension with the security claims. dependency_availability is 1: only CodeQL/Dependabot claims are present, with no lockfile contents or dependency audit evidence, so dependency availability and integrity cannot be confirmed. failure_messages is 2: the gate is fail-open by default and allows the call on timeout or unreachable control plane, so failure-path messaging and deny semantics are not clear enough.
audience_and_scenarios is 3: README and CONFIG.md cover desktop, hand-started server, paired devices and multiple agent scenarios. capability_boundaries is 3: per-capability switches (AGENTGLASS_TERMINAL_DISABLED / GIT_WRITE_DISABLED / DOCKER_WRITE_DISABLED) and the read/answer/full three-level permissions clearly bound capabilities. trigger_precision is 2: the gate is fail-open by default and allows the call on timeout or unreachable control plane, so trigger and deny precision is insufficient. environment_fit is 2: the Windows build is self-described as unverified on real hardware and macOS is unsigned and needs a manual quarantine clear, leaving environment-fit gaps.
information_architecture is 3: README, CONFIG.md, SECURITY.md, NOTICE.md and other docs are clearly layered. install_notes is 3: installation and setup:undo steps are clearly described. naming_stability is 2: no stability commitment is evident for naming and version evolution. examples_and_faq is 3: the docs provide examples and FAQ explanations. known_limitations is 3: SECURITY.md explicitly lists known weaknesses and limitations. license is 3: LICENSE states MIT and NOTICE.md mentions third-party icons. versioning_changelog is 2: no complete version and changelog evidence is present. maintenance_responsibility is 2: maintenance responsibility and publisher identity are unverified by FollowAgents and therefore unknown.
output_usability is 2: output usability is affected by the fail-open gate and permission semantics, requiring extra configuration for reliable use. marginal_value is 2: marginal value over existing options is limited and must be assessed per scenario. cost_benefit is 2: the in-app updater compiles code on the local machine and extra security configuration is needed, so cost and benefit must be weighed.
claim_traceability is 2: most claims trace to README, CONFIG.md, SECURITY.md and other files, but some behaviors lack direct evidence. cross_source_corroboration is 2: cross-document corroboration is limited, and dependency security rests only on CodeQL/Dependabot claims. fact_inference_separation is 2: fact and inference are partly conflated, e.g. publisher identity is unknown rather than suspicious and readers must separate the two.
- SECURITY.md itself concedes that an agent process holding the machine token could historically release its own held gate call, and that the token does not separate the user from their own agents; do not treat the gate as a security boundary.
- The gate is fail-open by default (timeout or unreachable control plane allows the call); only AGENTGLASS_GATE_FAILCLOSED=1 flips it to deny.
- A hand-started tokenless server is open to any local uid and exposes the terminal/shell; set AGENTGLASS_TOKEN on shared machines.
- After pairing, the device key travels as a bearer header over plain HTTP, and the handshake is not bound to the six-digit code, so an active on-path attacker is not defended against; use Tailscale or https.
- The Windows build is self-described as unverified on real hardware; macOS is unsigned and needs a manual quarantine clear; the in-app updater compiles code on the local machine.
- Dependency security rests only on stated CodeQL/Dependabot coverage; no lockfile contents or audit results are in evidence, so absence of known vulnerable dependencies cannot be statically confirmed.
FAQ
Does it replace Claude Code or my agent?
Does anything leave my machine?
Why is the approval queue safer?
How does the phone connect?
What about ignored files a new worktree needs?
git worktree add copies only the tracked tree, so a .worktreeinclude at the repository root names the ignored paths every worktree agentglass cuts should carry in, such as .env.