Memdoor Coding Workflows
Turn coding tasks into checked workflows that let smaller models tackle complex development work.
- Source repo
- guregodevo/memdoor
- Stars
- ★ 363
- Last updated
- today
- License
- Apache-2.0
- Primary language
- Go
- FA score
- 70/100 · Some gaps
At a glance
- How it runs
- Works with
- Universal · cross-platformOpenAI API · Claude APIChatGPT (Partial support)
- Cost
- Free software; you pay for model usage
- Setup effort
- Low · running in minutes
- You'll need
- Typical use
- A developer fixing a bug in a local repository can ask the terminal agent to change the code and run the project checks.
- Not a fit if
- Teams that require code to stay local but do not run a local model
- Users who need a chat UI outside the terminal or supported IDEs
- Source review
- 70/100 · Some gaps
What does this agent do, and when should you use it?
Memdoor is a Go coding agent and workflow runner with an interactive terminal interface and a headless CLI mode. Its coding agent reads project files, edits code, and runs checks; YAML workflows organize repeatable tasks into checked steps, parallel work, and approval gates. A local gateway connects it to providers including OpenRouter, Anthropic, OpenAI, and Gemini, or to local runtimes such as janis, Ollama, llama.cpp, LM Studio, and vLLM. Memdoor can serve an ACP session to Zed, JetBrains, or VS Code, and its workflows can run in GitHub Actions. Files, sessions, and commands stay on the machine running Memdoor, while content sent to a model goes to the selected provider.
Run memdoor in a project directory and the agent reads files for the task, uses tools, edits code, and runs checks; the terminal shows the work and check results. Scripts can start a headless turn with memdoor run and consume event output with --json. For repeatable tasks, YAML files define workflow steps and mario runs their dependency graph. Steps can specify requires conditions, a target check, a timeout, and an approval gate; failed workflows can resume at the failed step. Users can also run workflows with memdoor workflow run, expose an editor session with memdoor acp, or invoke built-in workflows from GitHub Actions.
- A developer fixing a bug in a local repository can ask the terminal agent to change the code and run the project checks.
- A team maintaining a repeatable release or review process can define steps, checks, and approval gates in YAML workflows.
- A team automating pull request review in CI can use
pr-revieworsecurity-reviewin GitHub Actions. - A developer using Zed, JetBrains, or VS Code can access Memdoor in the editor workspace through ACP.
- A team wanting open models on its own machine or an SSH-reachable host can connect janis, Ollama, llama.cpp, LM Studio, or vLLM.
How do you install or deploy this agent?
The installer is documented for macOS, Linux, and Windows; the README's terminal example is below. Set a provider API key for a hosted model, or connect a local model without a key. Building from source requires Go 1.25.
curl -fsSL https://memdoor.ai/install.sh | bash
export OPENROUTER_API_KEY=sk-or-...
cd your-project && memdoorConnect a local model instead:
memdoor connect localBuild from source:
git clone https://github.com/guregodevo/memdoor && cd memdoor
make build
cp memdoor ~/.local/bin/How do you use this agent?
Start the interactive agent in a project:
cd your-project && memdoorRun a headless task or pass a diff on standard input:
memdoor run "make the retry wait configurable and add a test"
git diff | memdoor run "review this diff; one line per finding"Run a workflow:
memdoor workflow run release --waitWorkflow files live under .memdoor/workflows/<name>/; from the terminal, /workflow:<name> [the task] starts one. To connect an editor, configure an ACP client:
{
"acp.agents": {
"Memdoor": { "command": "memdoor", "args": ["acp"] }
}
}What are this agent's strengths and limitations?
- Users can choose among multiple model providers or local runtimes; workflow YAML does not name a model.
- Workflows support checked steps, parallel tasks, approval gates, and resuming from a failed step.
- The documented interfaces include an interactive terminal, headless CLI, ACP editor integration, and GitHub Actions workflows.
- The README describes local data boundaries and documents OpenRouter request data-collection settings.
- With hosted models, content sent for model processing reaches the provider; free-model hosts may train on submitted content.
- Agent capability and model charges depend on the provider account, API key, or local runtime available.
- Editor use requires ACP client configuration, and repeatable workflows require writing and maintaining YAML steps.
- The README specifies Go 1.25 for source builds but does not detail installer prerequisites for each operating system.
How does this agent compare with similar options?
Memdoor combines a coding agent with resumable YAML workflows. Compared with a one-off agent task, a workflow can declare checks, parallel steps, and approval gates; the README distinguishes this approach from skills. It can use local runtimes such as Ollama, llama.cpp, LM Studio, and vLLM, or connect to several hosted model providers.
Key facts side by side with the most closely related agents.
| Agent | Source review | Form / cost | Stars | Updated | Language | Full support on |
|---|---|---|---|---|---|---|
| Memdoor Coding Workflows This agent | 70 · Some gaps | CLIFree + model costs | ★ 363 | today | Go | OpenAI API · Claude API |
| Poolside pool | 67 · Some gaps | CLIFree + model costs | ★ 441 | 2mo ago | — | OpenAI API |
| TAKT Workflow Orchestrator | 57 · Major gaps | CLIFree + model costs | ★ 1.4k | today | TypeScript | Codex · Claude Code · OpenAI API · Claude API |
| pigo | 68 · Some gaps | CLIFree + model costs | ★ 489 | 1mo ago | Go | OpenAI API · Claude API |
How does FollowAgents rate this agent?
Why each dimension lost points
The docs describe tool allowlists, a write root, destructive-command blocking, optional per-call approval, and encrypted and redacted secrets, so least privilege and confirmation have concrete controls. However, approval is automatic by default, coder reads may leave the workdir, and bash is not an isolation boundary. Data destinations and external hosts are described in detail, with the host list said to be constrained by a test; dependency security is supported only by pinned versions, with no vulnerability review or mitigation record provided. Installation, upgrades, network access, and remote sharing have external effects; downloads have checksum and optional signature checks, but checksum-only installation remains allowed when signatures are unavailable. No general rollback mechanism is described. The repository and upstream workflow are attributed, while publisher identity remains unknown.
The docs conflict on the default A2A policy: the sandbox security architecture says all agent pairs are allowed by default, while the authorization reference says deny all; the configuration guide says the default policy applies. This weakens consistency. Go dependencies are version-pinned and installation docs describe several runtimes, but upstream availability is not established. Failure states, exit codes, approval timeouts, and tool refusals are documented, though configuration-load errors fall back to defaults and not every failure has a clear diagnostic path.
The README covers interactive terminal use, scripts, CI, editors, remote hosts, workflows, and local models. Tool configuration, agent scopes, write boundaries, and explicit non-sandbox limitations describe capability boundaries; however, the default tool set can allow all tools, approval is off by default, and users must configure safeguards themselves. macOS, Linux, Windows, SSH, several model providers, and local runtimes are covered in useful detail.
Documentation is well organized across getting started, CLI, architecture, security, configuration, and examples. It gives concrete installation, source-build, key-setup, exit-code, and platform instructions. Product and component names are mostly clear, but configuration, legacy authentication, and authorization docs show signs of stale or conflicting material. Examples are extensive, but no FAQ-style troubleshooting guide is included in the supplied files. Known gaps include sandbox limitations and unimplemented configuration features. A complete Apache-2.0 license is supplied. Docs are dated and build dependencies are pinned, but no continuous changelog is supplied. Repository and issue links provide a maintenance path, but no explicit team commitment is shown and the publisher's enterprise identity is unverified.
Terminal output, JSON events, workflow results, exit codes, and file diffs support both scripting and human review. Agents, approval gates, parallel steps, and local models offer a clear workflow benefit; benchmark and token-saving claims are primarily project-authored and are not independently corroborated by the supplied material. Cost information covers local and provider models and usage reporting, but does not systematically compare operating or deployment costs.
The docs point to implementation files, settings, and logs, and provide commands for inspection; those implementation files are not among the supplied materials, so key claims cannot be cross-checked here. The README and architecture and authorization docs offer partial corroboration, but directly conflict on default A2A behavior. Benchmark, test coverage, and security claims are mostly documentary assertions; some name implementation locations or verification methods, but facts and promotional conclusions are not consistently separated.
- Commands and writes run automatically by default; coder reads may reach outside the workdir, and bash and browser automation are not fully sandboxed. Review tool configuration and enable approval for sensitive code.
- The supplied architecture and authorization docs disagree about the default agent-to-agent policy; verify the implementation and effective configuration at the target revision before adoption.
- Free-model requests may go to hosts that train on inputs; the installer can rely on checksums alone when signatures are unavailable.
Recent releases
Latest entries from the project's GitHub Releases. Notes are quoted from upstream as written, not rewritten or tested by FollowAgents.
-
v1.790.0 Memdoor v1.790.0
Release notes excerpt
One binary per platform; curl -fsSL https://memdoor.ai/install.sh | bash installs the right one from this release and checks it against SHA256SUMS.View on GitHub ↗ -
v1.789.0 Memdoor v1.789.0
Release notes excerpt
One binary per platform; curl -fsSL https://memdoor.ai/install.sh | bash installs the right one from this release and checks it against SHA256SUMS.View on GitHub ↗ -
v1.788.0 Memdoor v1.788.0
Release notes excerpt
One binary per platform; curl -fsSL https://memdoor.ai/install.sh | bash installs the right one from this release and checks it against SHA256SUMS.View on GitHub ↗
FAQ
Do I have to pay for a model?
Does my code leave my machine?
Will the agent run every command and write automatically?
MEMDOOR_APPROVE=changes to ask before every command and write; workflows can also pause at approval gates that show the diff.What happens when a check or workflow fails?
memdoor resume.