LoopForge built in 2 seconds in our sandbox, but its test command failed after 126 seconds. Consider it for a trusted development team that wants coding-agent work broken into reviewable stages. An operator serving untrusted customers or a team requiring an entirely English interface should look elsewhere before adopting the default server setup.
Approval steps are part of the delivery workflow
The README describes agent, script and human-gate nodes in an SOP, its name for a repeatable workflow. A human gate pauses a run for approval or sends work back to a chosen step. For a team already using coding agents, that is the reason to investigate LoopForge: make acceptance an explicit stage rather than a conversation someone has to remember.
The project coordinates CodeBuddy, Codex and Claude Code. Roles can have their own prompts, executors and rules, with Skills and MCP tools. Chat handles individual requests, while SOPs give recurring work defined stages. Those documented mechanisms describe how a team can organise work; they do not prove that separating roles produces a better code change.
What happened when we ran it
Our November 11, 2026 sandbox run installed LoopForge in 33 seconds and built it in 2 seconds, then failed the test command with exit 1 after 126 seconds. The measured commit was 29fbcc8, and 87 dependencies were recorded.
The structured result labels 23 entries passed and 5 failed out of 28. The supplied tail separately names six failing tests. Both records must stay visible: treating either as a reconciled count of individual cases would go beyond the evidence. The final output includes FAIL agentflow/internal/runtime, while schedule, scriptview and tracker package lines report ok.
Five named failures concern Docker sandbox or image behaviour, manager paths, or agent-state mounts. The other is TestWorkspaceTerminalInteractivePromptAndTabCompletion. These names locate the reported failures around runtime behaviour, but the tail contains no underlying assertions explaining them. It does not establish that Docker was unavailable, that permissions were wrong, or that the software fails on a supported deployment.
The recorded configuration specified 3 CPUs, 8 GB RAM and image golang:1.24-bookworm. That image label cannot establish the actual Go or operating-system version. The checkout held 2,818 files, approximately 359,736 source lines and occupied 72.8 MB. The scan found five CI workflow files, a Dockerfile and a Compose file, with no tests directory detected. Go test output already demonstrates why that directory observation cannot mean an absence of tests.
The advertised server route pulls an image
The README says start.sh pulls the release image pinned in compose.yaml rather than building the checkout. It creates MySQL and platform services, generates configuration and installs starter workflows. Host Go and Node.js installations are not required for that route. Our source-build result and that installation route answer different questions.
Real agent steps need credentials for the selected executor. GitHub authorization is needed when changing an existing connected repository or opening pull requests, while the script-and-approval demo needs no model key. Start with that demo when assessing whether the approval interaction fits your team before adding model access.
Claude Code is installed from npm on first use and cached, according to the README, so that first use needs npm access. This is another reason a source build cannot settle readiness for the actual executor your team chooses.
Default deployment assumes trust between users
The README explicitly says the default Docker-socket setup is for trusted teams rather than untrusted multi-tenant isolation. It also says signed-in users can read project data across the instance. Those are concrete reasons to reject the default architecture for customers who need separation from one another.
New installations listen on all interfaces, and the first account becomes administrator. The README tells operators to restrict access until that account exists and to arrange HTTPS before wider exposure. Assign someone to those steps before issuing invitations. A workflow with human approval still needs an access model suited to its users.
The language boundary matters too. Management pages support English and Chinese, but the chat workbench is currently Chinese. English documentation exists; an English README does not make every interactive screen usable for an English-only team.
Local workflows and general automation answer different needs
LoopForge Local brings built-in workflows into a coding assistant without the shared server. The README says exporting a platform SOP for standalone local execution is planned. Choose between the built-in local workflow and shared platform before investing in a custom SOP you expect to carry between them.
Dify combines AI workflows, retrieval and model management for LLM applications. Choose it when that application is the product. n8n combines a visual canvas with custom code for agents and workflow automation. Consider it when connecting services is the main job, and review its fair-code licensing for your use.
GitHub records LoopForge's last push on November 12, 2026, alongside issue and pull-request updates that day. Its latest release endpoint lists v0.3.6, published November 11. That shows current maintenance activity, not resolution of our runtime failures.
What we have not tested yet
We have not reproduced the image-based deployment, connected an executor, completed a repository change, exercised approvals or measured output quality and model costs. Browser behaviour, Local workflows, MCP operation and access controls remain outside the run. The failure-count discrepancy and underlying runtime assertions need full logs. Community research was not collected.
Only documentation receives a numerical score: 1 means missing essentials, 2 major gaps, 3 a usable basic route, 4 explicit operational choices and boundaries, and 5 independently checked coverage. LoopForge earns 4 for documented deployment, credentials and trust boundaries. Before connecting a working repository, complete the script-and-approval demo and resolve the failed runtime checks.