Electron desktop app that orchestrates teams of Claude Code, Codex and OpenCode agents with a kanban board, messaging, review and budgets.
github.com/777genius/agent-teams-ai · 2026-10-04 · f8d3434
Defense-in-depth score
1.6 / 10
Agent Teams AI launches every teammate with Claude's permission prompts bypassed by default, and its terminal automation auto-accepts the runtime's 'trust this folder' and bypass-permissions warnings. Agents run unsandboxed as the user with the full shell environment, so a single prompt injection in a repo, web page or peer message can exfiltrate credentials and push or delete with no human involved. A real per-call approval sheet exists, but it is opt-in and still pre-allows file writes through a project settings file.
Agent Teams AI keeps the provider keys it manages in the OS keychain, redacts its crash reports, and includes a real per-call approval sheet. As shipped, teams launch with auto-approve on and every agent runs unsandboxed with your full environment, so the safest setup turns approval on and builds the boundaries around the app yourself.
| Setup | How | What it gives you |
|---|---|---|
| Scoped, low-limit keys | Give the app provider keys with a spending limit set at the provider, and repository tokens scoped to the repositories the team works on, read-only where the task allows | The provider and the code host enforce what any teammate can spend and reach, whatever it is asked to do C8 |
| A dedicated OS account | Run the app from an OS account that holds only the credentials this work needs, with no personal cloud, SSH or git logins in its shell | Teammates inherit a small environment, so a hijacked agent reaches only what that account holds C1 |
| Per-call approval | Untick Auto-approve all tools each time you create or launch a team | Each tool request waits in an approval sheet that shows the exact command or input and a diff C2 |
| Repositories you have read | Launch teams only in repositories whose Claude and Codex settings, hooks and project MCP servers you have read | The project settings the app trusts on your behalf come only from sources you have checked C6 |
| Separate teammate worktrees | Tick Worktree for all teammates in the members editor | Each teammate's file edits land in its own git checkout, apart from your main working tree C4 |
| Capped scheduled runs | Run unattended work as a schedule with Max turns and Max budget (USD) set | Runs nobody is watching stop at a turn count and a dollar ceiling C10 |
| Its own VM | Run the app in a VM whose network reaches only the model providers and the hosts the task needs | An outer boundary around agents' shell commands and MCP servers, and a narrow path for data to leave C4 |
| Transcripts kept elsewhere | Copy the session transcripts under ~/.claude/projects to storage the agents can't write to | A record of every teammate's tool calls that outlives the session and stays as it was written C9 |
0.00 / 1.00
Every teammate runtime runs as the desktop user with the app's full process environment merged with the user's interactive-shell environment, so cloud CLIs, SSH agents, gh tokens and provider API keys are all reachable. There is no scoped identity or per-request authorization layer between the agent and those credentials. Team-launch control paths are not locked down. A hijacked teammate holds the user's whole account across services.
0.25 / 1.00
Teams launch with Claude's permission prompts disabled by default: the 'auto-approve tools' toggle starts on, and the app passes --dangerously-skip-permissions with bypassPermissions to the lead, every teammate and scheduled runs. An approval mode exists when the user unticks it; it routes each tool request to an in-app sheet that shows the exact command, JSON input and a diff. Even in that mode the app writes allow rules for Edit, Write and NotebookEdit into the project's .claude/settings.local.json, and an 'allow all' button flips the team to auto-approve. File changes can be rejected afterwards through the review panel, but shell side effects cannot.
0.07 / 1.00
The consequential tools are the runtime's own general-purpose ones (Bash, Write, WebFetch), passed through with no argument validation added by this project. The app's own MCP tools for tasks, messages and kanban use typed zod schemas and check that the team exists, but they take model-chosen file paths and directories. The default tool set includes shell, write and network; the app removes only a few orchestration tools (team launch and stop, TeamDelete). A misused tool can reach the whole machine.
0.15 / 1.00
No sandbox of any kind wraps the runtimes the app launches: no container, OS sandbox profile or seccomp/landlock policy, and the processes run with the user's full environment. The only separation is an optional per-teammate git worktree, which is a separate working directory, not a boundary, and is off by default. Model-written commands therefore run directly on the host as the user.
0.00 / 1.00
Teammates read repository files, web content and messages from other agents and other teams, and nothing in the orchestration layer marks or limits that content. Because the default launch bypasses all permission prompts, an injected instruction can make a teammate exfiltrate secrets over the network and take irreversible actions such as pushing code, with no human involved. Cross-team messaging lets one team's agents instruct another team's agents. Rendered markdown is sanitized, but not on every rendering path.
0.10 / 1.00
The app automatically answers the runtime's 'trust this folder' prompt and its bypass-permissions warning by sending keystrokes to the terminal, and pre-marks Codex projects as trusted. That removes the user decision that normally gates a repository's own settings, hooks, MCP servers and instruction files. Team tasks, comments and messages persist on disk and are re-injected into teammates' context in later sessions, with no provenance or review. Agents can also write into other teams' inboxes.
0.13 / 1.00
MCP servers installed from the app's catalog run via 'npx -y' with the registry-supplied version when there is one and the latest package otherwise, with no integrity check. The user chooses each install explicitly, but project-scope MCP servers from the repository still load through the runtime's native settings once the app has auto-accepted workspace trust. Every MCP server runs as the user with the full environment.
0.28 / 1.00
Provider API keys that the app manages are encrypted at rest through the OS keychain, and Sentry error reports pass through a redaction filter for tokens, emails and keys. Those keys are then placed in the runtime's environment together with the user's entire shell environment, where any teammate can print them with Bash, and nothing redacts what goes to the model. Sentry crash reporting is on by default unless the user turns telemetry off. Runtime stdout/stderr logs are written with owner-only permissions but not redacted.
0.45 / 1.00
Each teammate's actions are recorded in the runtime's structured session transcript under ~/.claude/projects, which the app parses to show per-task tool calls, and the app writes per-member stdout and stderr logs with owner-only permissions. Approval decisions are not durably recorded by the app, and the records sit in the user's home directory where the agent, running unsandboxed as that user, can rewrite them. Writing is best-effort with no fail-closed behaviour.
0.15 / 1.00
Interactive teams, the main mode, launch with no turn, time or spend cap; the monthly token and cost budgets only raise alerts at 80% and 100%. Scheduled runs are better bounded, with a 50-turn default and an optional dollar cap passed to the runtime. Stopping a team kills the tracked CLI process trees, including a SIGKILL sweep, but background services that agents register are a separate list.
SafetyCard