What This Stack Does
This stack assembles a local-first terminal workflow around Goose and OpenCode, with Ollama providing local model inference, DesktopCommanderMCP exposing carefully limited filesystem and process actions, and tmux keeping every control surface visible. It is designed for developers who want source code and routine prompts to remain on their machine whenever the selected model and extensions permit. Local-first is a boundary you configure, not a promise that every command stays offline by default.
Goose acts as the primary task-running agent, while OpenCode provides a second coding or review lane that can use a different model route. Ollama supplies models that run on local hardware, and tmux separates agent, model, logs, and tests into observable panes. DesktopCommanderMCP is the most privileged component because it can bridge an agent to files and processes. Treat that bridge as an allowlisted capability, not as a convenience switch that receives unrestricted home-directory access.
Privacy Model and Trust Boundaries
Begin by classifying the repository and the data it contains. Decide which paths may be read, which paths may be modified, whether dependency downloads are allowed, and whether any prompt may leave the machine. A local Ollama endpoint can keep inference local, but Goose or OpenCode may still use cloud providers if configured that way, and MCP servers may reach external services. Document each outbound route and test the workflow with network access disabled before calling it private.
Create a dedicated workspace copy or Git worktree and expose only that path through DesktopCommanderMCP. Deny access to SSH keys, browser profiles, password stores, cloud configuration, production dumps, and unrelated repositories. Use project-scoped environment files containing non-production credentials, and remove them from agent-readable context when not needed. Logs should record tool names and outcomes without copying secrets or full proprietary files into a long-lived transcript.
Install and Wire the Components
Run Ollama as a separately observable service and choose a model that fits the available memory and the task. Verify the model endpoint before connecting an agent. Configure Goose for the primary workflow and OpenCode for an independent review or fallback role. Keep provider keys distinct so switching from local inference to a hosted model is an explicit action. In tmux, reserve panes for Ollama logs, Goose, OpenCode, tests, and the operator shell.
Add DesktopCommanderMCP only after the agent can operate in read-only mode. Start with a narrow directory allowlist and harmless commands such as listing files or running a project test. Expand permissions one capability at a time, then record why the additional authority is required. If the MCP bridge cannot express a safe boundary for the task, do not compensate with a broad grant; use direct human-operated commands and let the agent consume only the resulting output.
Local Development Workflow
Give Goose a concise issue, the allowed paths, expected verification commands, and the rule that it must stop before destructive operations. Let it propose a plan, inspect the repository, and make a small patch. Run tests in a separate pane so a stalled agent cannot hide the state of the build. OpenCode can then review the diff against the original requirements, look for missing cases, or attempt a second patch in another worktree when independence matters.
Keep model changes visible. A local model may be adequate for code search, mechanical edits, and test scaffolding, while a hosted model may be justified for a difficult design decision. Escalation should be an operator decision with a clear data disclosure note. Do not automatically forward an entire repository or previous transcript when switching providers. Send the minimum context needed and preserve the local lane as the audit trail.
Performance, Cost, and Reliability
Local inference exchanges subscription or API spend for hardware limits, electricity, setup time, and slower responses on some machines. Measure useful engineering outcomes rather than tokens alone: time to a passing patch, retries, test coverage, and human cleanup. Keep model size and context within the machine budget so the terminal remains responsive. When Ollama is overloaded, queued requests from two agents can look like reasoning failures even though the bottleneck is local compute.
Design for graceful fallback. Pin working model and agent configurations, keep a known-good test command, and make the MCP permission file reviewable. If a local model repeatedly fails the same task, stop rather than granting more filesystem authority. A hosted fallback may improve the answer, but it changes the privacy and cost model. Record that transition and remove secrets or sensitive paths from the context before retrying.
When to Use It and the Bottom Line
Use this stack for private prototypes, offline-friendly repository work, learning local models, and controlled automation on a developer machine. It is a poor fit for unattended production changes, regulated workloads without a reviewed control design, or tasks that depend heavily on cloud-only systems. Local-first tools reduce one class of exposure, but an unrestricted process bridge can create a larger local security risk than a carefully scoped hosted workflow.
The safe pattern is Goose for primary execution, OpenCode for an independent lane, Ollama for optional local inference, DesktopCommanderMCP for narrowly approved actions, and tmux for operator visibility. Keep the worktree disposable, the MCP allowlist minimal, and cloud escalation explicit. Those constraints make the stack useful; removing them turns local convenience into hidden authority.