Six agents cover the path from issue triage to retrospectives
Fullsend v0.43.0 ships six named roles: triage, prioritize, code, review, fix, and retro. They work through the repository's existing issue and pull-request surfaces, so the useful comparison is with an engineering platform, not a clever editor plug-in. A code agent can implement a triaged issue, a review agent can inspect the result, and a retro agent can study the completed workflow. GitHub, GitLab, and Forgejo are named as supported hosts.
The codebase matches that ambition. Our checkout had 1,998 files, roughly 416,898 lines of source, and 36 MB before installation. Go carries the main CLI and orchestration code, while a Node workspace builds documentation and site pieces. Configuration lives with each enrolled repository under .fullsend/, and the architecture separates dispatch, infrastructure, sandbox, harness, and runtime. You are adopting a control system, not adding one command to a developer laptop.
GitHub setup needs five apps and an inference trust path
The v0.43.0 GitHub guide lists five agent applications for the standard roles, with a separate dispatch app in organization mode. Setup also requires the Fullsend CLI, an authenticated gh client, repository administration, and a model credential path. The recommended Claude route provisions short-lived GCP credentials through Workload Identity Federation. OpenAI models can use OpenAI workload identity, with a repository API-key secret documented as a fallback.
That is a serious amount of machinery before the first /fs-triage comment. Our npm install used 991 MB after pulling 624 packages, yet those dependencies cover only the web and documentation workspace we exercised. A live installation also creates workflows, secrets, variables, app permissions, and repository configuration. Teams that already manage CI identity and cloud policy will recognize the work. A three-person product team may reasonably decide that the operating surface costs more than the automation saves.
What happened when we ran it
Our sandbox installed the checkout at commit b9e5099 in 27 seconds. It added 624 npm packages and occupied 991 MB on disk. The project had no generic build script or target, so the lab skipped the build step instead of pretending that another command was equivalent. Vitest then passed 75 of 75 tests in 6 seconds. Npm audit found 0 known vulnerabilities across critical, high, moderate, and low severities.
Those results need a narrow reading. The repository's package file identifies itself as fullsend-web, while contributor instructions build the main Go binary with make go-build. We did not compile that Go binary, provision workload identity, install forge applications, or let an agent change a repository. The checkout had 28 CI workflow files and no Dockerfile or top-level tests directory. The passing 75-test run is useful evidence about the npm workspace, not proof that autonomous merging will behave safely in your organization.
Claude is stable while Codex remains experimental
Fullsend's v0.43.0 runtime guide calls Claude Code the stable default. Pi and Codex are marked experimental, and neither has completed a fleet pilot according to that guide. Codex can use OpenAI models through the secretless credential path, but it has no sub-agent roster. The maintainers recommend keeping review and retro roles on Claude Code when testing it. That caveat matters if an OpenAI-only policy brought you to the project.
Runtime choice is one layer among many. The 28 workflow files in our measured checkout reflect how much behavior sits around the model call: dispatch, authorization, sandbox setup, output validation, status reporting, and retries. Fullsend validates structured agent output at the harness level and uses distinct app identities for roles. Those are sound boundaries. They still require someone to select permissions, inspect failures, update the installed workflow files, and decide which generated changes may merge.
CODEOWNERS is the human safety boundary
In v0.43.0, the autonomy guide recommends a binary choice per repository, then uses CODEOWNERS to reserve sensitive paths for people. It names security policy, API contracts, deployment files, agent configuration, prompts, and CODEOWNERS itself as likely protected areas. Before autonomous mode, the guide recommends shadow mode: agents make decisions, humans still approve, and the team compares the two. Its graduation criteria remain explicitly undecided.
The project's own threat model is frank about unfinished protection. In our 3-CPU, 8 GB sandbox, the npm checks were clean, but they cannot answer whether a bot should merge production code. The threat document says the current JSONL audit trail is append-only by convention and can be modified by a process with workspace write access. It discusses hash chaining and an external write-once sink as possible defenses. Regulated teams should treat that as an open requirement, not a footnote.
September activity is high, and much of the queue is automated
GitHub showed a push on September 23, 2026, with v0.43.0 released on September 9. The repository had 139 stars, 1,946 open issues, and 126 open pull requests when checked. The raw volume overstates ordinary community participation because many items are filed or handled by Fullsend's own agents. Still, same-day commits and a recent release establish active maintenance far better than the star count alone.
The live issue queue also exposes operating lessons. Issue #3221 asks Fullsend to stop dispatching agents for bot-authored dependency updates after trivial changes consumed tokens. Other current reports cover duplicate runs and workflow statuses that disagree with the agent's posted result. Passing 75 Vitest tests in 6 seconds makes the repository easy to inspect, but adopting it should begin with one repository in shadow mode. Give CODEOWNERS the final word until your own review history says the agents deserve more.