SquadCue
Workflow & Automation · tested 2026-08-19 · re-test due 2026-11-19 · by the Hlido desk, not the vendor
In short: A local cockpit that turns your Claude Code sessions into named 'employees' you supervise through an approval inbox — early and single-user, but unusually honest about exactly what it is and isn't.
Quick answer
SquadCue scores 73/100 (STEADY) on Hlido’s independent, hands-on test (reviewed 2026-08-19). STEADY (73) for an MIT-licensed, genuinely useful local cockpit (session-as-employee, canvas pipelines, a real human-in-the-loop approval inbox) whose standout is exceptional honesty about its own limits and non-security Pricing: Open source (free entry point documented).
SquadCue (MIT, v0.1.2) is a laptop-scale control plane for AI CLI sessions. Recent Claude Code sessions on your machine become named contacts you chat with, resume across restarts, and supervise from your phone; a visual Drawflow canvas orchestrates repeatable pipelines on top. Its centrepiece is an approval inbox: with tools allowed, a PreToolUse hook routes risky actions (shell, file writes, network fetches) into a web + Telegram queue where the first response wins and a timeout means deny. What earns Hlido's respect is the honesty. The project states plainly and repeatedly that the inbox is a supervision workflow for a trusted local setup, not a security boundary, points to a SECURITY.md that spells out what it cannot stop, and documents its opt-outs, its loopback-only enforcement, and a production 'learned the hard way' caveat that background jobs spawned in a chat turn may die with it. That candour is rare and valuable. The trade-off is maturity and reach: it is explicitly single-user by design, Windows is the daily-driver platform (canvas shell nodes run via PowerShell; session relaunch is Windows-only today), Claude Code is the only first-class engine (Codex is a red-team add-on, other CLIs a roadmap adapter), and the whole thing was extracted in July 2026 from one person's tooling. The 'immortal employees' durable-memory model is roadmap, not shipped. Reviewed from the project surface only; Hlido did not run the cockpit.
Why STEADY
STEADY (73) for an MIT-licensed, genuinely useful local cockpit (session-as-employee, canvas pipelines, a real human-in-the-loop approval inbox) whose standout is exceptional honesty about its own limits and non-security-boundary status — held at low-medium confidence by early-stage maturity (v0.1.2, single-user by design, Windows-primary, Claude-Code-first) and a surface-only review. The candour raises trust; the maturity caps the score.
What we saw
4 screenshots captured by the Hlido engine during the reviewed run (run-22cf84e4e27007f0-squadcue-com). Our own captures — not vendor marketing material.
What it does well
- Turns real Claude Code sessions into named, resumable 'employees' you chat with and supervise — a concrete, useful local abstraction
- A real human-in-the-loop approval inbox (web + Telegram, first-response-wins, timeout = deny) with recorded, auditable decisions
- Exceptionally honest self-documentation: it states the inbox is not a security boundary, links a SECURITY.md of what it cannot stop, and flags hard-won production caveats
- Sensible local security posture — loopback-only enforced at startup, CSRF/DNS-rebind guards, path containment, SSRF guard on fetch, no shell template interpolation
- Zero-infra install (pip install squadcue; plain JSON/JSONL + SQLite state you can grep); MIT-licensed
What it fails at
- Early stage — v0.1.2, extracted from one person's tooling; durable cross-session 'immortal employee' memory is roadmap, not shipped
- Single-user by design (loopback only; no auth/RBAC until a second user exists)
- Windows is the daily-driver platform — canvas shell nodes run via PowerShell and session relaunch is Windows-only today; Linux/macOS need adaptation
- Claude Code is the only first-class engine; Codex is a red-team add-on and other CLIs are a roadmap adapter layer
- Surface-only review — Hlido did not run the cockpit, so behaviour is unverified
Red flags
- By the project's own statement, the approval inbox is a supervision workflow, not a security boundary — approving a shell command approves the whole program it runs; do not treat it as a sandbox
Best for
- Solo operators running Claude Code (and optionally Codex) all day who want a local cockpit with named sessions and phone-based supervision
- Users who want a real approval gate over risky agent actions and value plain, greppable local state
- Windows-primary developers comfortable with an early, honestly-scoped open-source tool
Not recommended for
- Teams needing multi-user access, auth or RBAC
- Anyone expecting the approval inbox to be a security sandbox — it is explicitly not
- Linux/macOS users wanting full parity today, or users of CLIs other than Claude Code/Codex
Pricing & access
- ModelOpen source
- Free entry pointYes — a free tier or open-source edition is documented
Derived from Hlido-held evidence only (engine checklist + editorial text); quotes are verbatim from the scorecard; not vendor-supplied; re-derived daily. Verify current prices on the vendor's pricing page. Last verified 2026-08-18.
Related agents
Agent relevance
API CLI Behavioral-testable
Agentic-Commerce Readiness 48/100 · SURFACE-ONLY
Independent readiness for agent delegation & transaction. How it’s scored · check live
Install via pip and run locally (FastAPI server + single-file cockpit); it discovers Claude Code sessions as 'employees', routes risky tool calls through an approval inbox (web + Telegram), and orchestrates pipelines on a canvas. Control plane and state stay on your machine.
Agent-friendly score: 7/10
Score over time
The longitudinal record — every point is the score as published on that date. Raw series.
Evidence
- Turns real Claude Code sessions into named, resumable 'employees' you chat with and supervise — a concrete, useful local abstraction — source (2026-08-19) verified
- A real human-in-the-loop approval inbox (web + Telegram, first-response-wins, timeout = deny) with recorded, auditable decisions — source (2026-08-19) verified
- Exceptionally honest self-documentation: it states the inbox is not a security boundary, links a SECURITY.md of what it cannot stop, and flags hard-won production caveats — source (2026-08-19) verified
- Sensible local security posture — loopback-only enforced at startup, CSRF/DNS-rebind guards, path containment, SSRF guard on fetch, no shell template interpolation — source (2026-08-19) verified
- Hands-on runtime behaviour (executing the tool / a live task) — source (2026-08-19)



