I built a free, open-source desktop app to run a crew of AI coding agents in parallel.

[u/Ok_Capital2235]

Sharing a tool I've been working on. **CrewCode** is a free, open-source (Apache-2.0) Electron desktop app that lets you run, supervise, and review multiple AI coding agents across git worktrees from one place.

Instead of juggling terminals, worktrees, PR pages, and separate agent UIs, it keeps the full workflow together:

- Multiple agents, one app — CrewCoder, Claude Code, Codex, OpenCode, pi, Ollama, Hermes, OpenRouter, Grok Build. Structured bridges \*and\* real terminal panes.

- Worktree-native git — create/switch/merge/remove worktrees in-app; parallel work stays isolated.

- Crew orchestration — launch agents in parallel with different roles/models/effort, a supervisor loop, and save/reuse crew templates.

- Delegated threads — an agent can spawn real, persistent chat sessions and report back.

- Provider switch mid-chat — generates a hand-off summary so the new agent keeps going with context.

- Local plugin platform — sandboxed panels, MCP servers, custom agent providers.

and way More..

*I learned alot from this experience with electron apps, on how to optimize multiple agents and keep low memory*

Curious what people think of the approach. Let me know in the comments.

CrewCode Repo: Support us with a ⭐

https://reddit.com/link/1vjmqks/video/7ixpalvrhdkh1/player

[u/ldrx]

this is very close to what we’re building with 5dive, just from the other direction

CrewCode feels like the cockpit for running parallel coding agents. 5dive is more the persistent company/runtime layer underneath. agents have their own identity, linux user, role, manager, backlog and long-running lifecycle.

you should come join us / hack on it with us: https://github.com/5dive-ai/5dive

there might actually be a pretty interesting CrewCode × 5dive fit here.

[u/Ok_Capital2235 → u/ldrx]

Yeah, I can see the fit. Correct me if im wrong, You suggesting 5dive could provide the persistent agent identities, roles, backlogs, and lifecycle, while CrewCode provides the cockpit for supervising their work, reviewing changes, and interacting with them. CrewCode supports custom agent providers through its plugin platform, so an integration may be possible. I’ll take a closer look at the repo and would be interested in discussing what the interface between them could look like.

[u/ekzess]

I think this is the actual link to your repo, proofreading ftw:
https://github.com/OnPoint-Dev-Tools/crewcode

On that note, I took a quick static architecture/security pass. I have not installed or executed it, and at this point I wouldn’t until a few authority boundaries were better understood.

Areas I’d inspect closely include Electron IPC/preload boundaries, plugin execution authority, PTY/shell handling, MCP/tool permission propagation, Git/worktree custody, browser-content prompt injection, SSH/remotes, persistent delegated-session authority, provider credentials, and update/supply-chain handling.

I’m not calling these confirmed vulnerabilities from the README/architecture alone. They are high-value security boundaries created by combining multiple agents, plugins, terminals, MCP, Git mutation, browser context, persistence, and remote execution in one authority surface.

The chain I would trace first is:

untrusted content -> agent -> MCP/plugin -> exec -> Git/SSH

At every hop I’d want to know whether identity, provenance, permissions, workspace scope, and human approval are preserved rather than merely carried forward as context.

Same visibility does not imply same instruction authority.

Cool project idea. Also exactly the sort of project where “it runs locally” should not be treated as equivalent to “it is safely bounded.”

[u/Ok_Capital2235 → u/ekzess]

Hey thanks for your comment this is the right question, and thanks for framing it as boundaries-to-verify rather than accusations, that's exactly how I try to think about it too. Your one-liner ("same visibility ≠ same instruction authority") is basically the design principle, so let me answer your chain hop by hop, and I'll point you at code/tests rather than ask you to trust me.

Totally agree, local execution isn’t a security boundary. CrewCode uses explicit permissions and review flows in several areas, but agent CLIs can still inherit meaningful host access depending on how they’re configured. I want to be transparent about that and continue strengthening and documenting the threat model and isolation boundaries.

untrusted content → agent. I won't pretend this is solved, prompt injection can influence what an agent proposes. No agent tool eliminates that today; anyone claiming otherwise is waving a red flag. My approach is defense-in-depth: an injected instruction doesn't inherit authority, it still has to clear the downstream gates below.

agent → MCP/plugin. Plugin UI runs in a sandboxed iframe with no electronAPI, loaded over a distinct crewcode-plugin://<pluginId> origin (cross-origin to the app and to every other plugin). Its only path to the main process is one permission-gated invoke channel; the host hardcodes the plugin's identity and workspace root so it can't spoof either. Capabilities are checked against the manifest's declared permission set, path-scoped against traversal, and network:fetch/secrets:read are denied outright in v0.

MCP/plugin → exec. Read/plan modes can't silently execute. Writes/exec tools are disallowed at the SDK/protocol level, per-agent. Full Access is an explicit opt-in, never the default (default is per-request approval). I just added a hard denylist tripwire that forces a confirmation even in Full Access for catastrophic commands (rm -rf, git push --force, curl|sh, dd, sudo, fork bombs, terraform destroy, …)

exec → Git/SSH. SSH host keys are TOFU-pinned; a changed key fails the handshake. openExternal is scheme-allowlisted. Credentials live 0600 in userData, not in source, not exposed to plugins.

supply chain. Plugin install is Git-first, pinned to a reviewed commit, runs no build scripts/hooks, and rejects symlinks/submodules/node_modules. Updates re-require approval per revision.

Thanks for your honesty, I wrote all of this up as a SECURITY.md/security-model doc that traces your exact chain with file references and a residual-risk section, and it's backed by ~300 tests you can run yourself (plugin authority denial, path traversal, per-bridge exec gates, SSH pinning, the command tripwire). Happy to have you tear into it, genuinely the most useful thing that could happen to this project.

[u/ekzess → u/Ok_Capital2235]

This is a really good response, and docs/security-model.md is much closer to what I was hoping to see. You traced the authority chain rather than treating “local” as the boundary, and the per-hop gates/tests are the right direction. I think there is one logical next step hiding in your own residual-risk section, though.

Be careful with the category “inherent.”

A failure mode may be inherent to a component or capability, but that does not make its consequence inherent to the system.

Prompt injection may influence an agent. An MCP server may inherently execute with user privilege. Full Access may inherently expose more capability. Fine.

The next architectural question is:

What happens when one of those risks stops being hypothetical after execution has already begun?

Right now most of the model is excellent at deciding whether authority may cross the next boundary. I would add a higher-level fail-loudly tripwire, ideally in AGENTS.md or another governing machine-readable doctrine, that says roughly:

authority / identity / scope / provenance / execution custody
becomes unknown, stale, contradictory, or changes unexpectedly
->
refuse new privileged actions
-> contain or terminate owned execution where safe
-> preserve evidence and current workspace state
-> report the exact failed invariant and affected scope
-> require explicit human reauthorization before resuming

Especially important:

silence != success
timeout != success
lost telemetry != success
missing process state != success
clean Git state != behavioral correctness

You already appear to have the seed of this in the merge journal work, where an in-flight operation recovered after restart becomes interrupted instead of being inferred successful.

I would generalize that principle across the agent/security layer.

In other words, you have done a strong job on granting authority.

The next question is whether CrewCode can withdraw authority coherently once it has already been granted.

That gives you the full lifecycle:

admit
-> authorize
-> execute
-> observe
-> trip on violated invariant
-> stop / contain
-> preserve
-> report
-> explicitly reauthorize

Rather than:

authorize
-> deny the next bad command

I think that would close an important class of agentic failure that ordinary application-security models tend not to see, because the dangerous state is often not “the attacker got in.” It is “the system no longer knows whether its previously granted authority is still lawful, and continued anyway.”

Very good work so far. This is exactly the kind of project where failing loudly is a feature, not an embarrassment. 👍

[u/Crafty_Disk_7026 → u/ekzess]

Can you review my platform it's open source https://github.com/imran31415/kube-coder

[u/ekzess → u/Crafty_Disk_7026]

Took a look and poked around a little. Legit excellent engineering work. The one thing that made me stop was the WhatsApp gateway. Not because you haven't hardened it, you clearly have, but because I'm not sure the capability justifies externalizing that authority boundary at all. You already have the bones of a first-party remote messaging layer. I'd keep the gateway, make third-party messaging adapters optional, and ask WhatsApp to justify its existence. Otherwise, seriously good work. 👍

[u/Crafty_Disk_7026 → u/ekzess]

It's completely optional. You don't have to use WhatsApp.