Crewyard
GitHub1 stars (opens in a new tab)Download
Security

What Crewyard does with your keys and your code

Crewyard runs on your machine and drives agent CLIs with your own accounts. These are the rules it keeps, and the places where it cannot protect you.

01API keys

  • On Windows, keys are encrypted with DPAPI for your user account. On macOS and Linux they go through Electron's safeStorage (Keychain, Secret Service or KWallet), and Chromium's plain-text fallback is refused.
  • A key reaches a runner only as an environment variable of that runner's process. It never goes on a command line, into a log, into git or into a URL.
  • Each runner's own setting keeps the key out of the commands its agent runs (Claude Code's subprocess scrub, Codex's shell environment policy, a guard plugin for OpenCode, Gemini CLI's variable redaction).
  • Not covered: a runner process holds its own key, so an agent that can read that process's memory is outside what environment rules can stop.

02Accounts and sign-in

  • Subscription tokens are never read, copied or relayed. Codex, Gemini CLI and OpenCode sign in through their own login flows, each in its own config folder.
  • Claude profiles use Anthropic or Anthropic-compatible API keys only; a claude.ai sign-in is never offered, and Claude subscription limits are never shown.
  • Crewyard never touches your default ~/.claude, ~/.codex or ~/.gemini folders.

03No network listener

  • The app opens no TCP listener. The window talks to the daemon over Electron IPC.
  • Outside callers, such as the report server every run gets, use a per-user named pipe on Windows or a 0600 Unix socket in a private folder on macOS and Linux, with a token.
  • The dev-server preview loads only loopback addresses on the task's own ports, in an isolated in-memory session with no access to the app.

04Approvals

  • Push, pull request, merge, delete and spend past a cap always wait for your approval in the app.
  • Commands are sorted into risk levels. High-risk ones (destructive git, anything outside the project, credential paths, package installs) are approved one at a time; an allowlist entry never matches a command with shell syntax.
  • Instruction files and skills an agent reads are untrusted text; they never change a role's permissions, the allowlist or the spend caps.

05Builds and updates

  • The builds are unsigned. Compare the SHA-256 on the download page with your file before you run it.
  • They have no update feed and never check for updates.
  • A packaged build refuses to start with remote debugging switches, so no DevTools listener opens.
  • Signed builds are prepared: they install only updates that Windows verifies as signed by the same publisher.

06Reporting a problem

The design decisions behind these rules are written down: secrets in ADR 0002, macOS and Linux in ADR 0010, signing and updates in ADR 0011, and Autopilot's limits in ADR 0017.

To report a security problem, use the repository's Security page on GitHub rather than a public issue. Everything else goes to issues. See also the FAQ.