squadcue

Security model

Threat model: single trusted user on their own machine, server bound to loopback. SquadCue refuses to start on a non-loopback host — there is no authentication layer, by design, until one exists.

Guards in place

Data provenance (what you see on first launch)

The Employees tab lists Claude Code sessions discovered locally from ~/.claude/projects on your machine — that’s where the Claude Code CLI itself stores conversation logs. SquadCue only reads them to offer resume/rescue; it never uploads, indexes remotely, or transmits this list anywhere. If seeing your sessions listed surprises you, that’s the intended discovery feature working on your own local data. Point claude_projects in squadcue.json elsewhere (or at an empty dir) to opt out.

Approval requests, run logs, and flow state live in plain JSON/JSONL/SQLite files inside the repo directory — greppable, deletable, yours.

Known limitations (accepted for the localhost single-user model)

Documented deliberately rather than hidden — pull requests welcome:

  1. No auth. Any local process can call the API. Loopback binding is the boundary.
  2. Prompt injection: content fetched from the web / files / issue text flows into agent prompts. When you enable “allow tools”, you are trusting that content. Keep allow-tools off for flows that ingest untrusted input.
  3. Child env: apart from ANTHROPIC_API_KEY, child processes inherit your environment (an allowlist is planned).
  4. readfile nodes can read any file your user can — treat flow definitions as trusted config.
  5. Frontend uses inline handlers with manual escaping; a CSP/refactor is planned.
  6. Flow-node agents are not covered by the global spawn semaphore yet — a runaway flow can spawn many CLI processes.
  7. Windows is the primary platform; session relaunch is Windows-only today.

Report issues via GitHub Issues.