What This Private Local Workflow Solves
This stack creates a local-first coding loop with clear responsibilities instead of treating one agent as an all-purpose autonomous developer. Ollama serves the model on the workstation, Cline provides an editor-based planning and implementation lane, Aider provides a Git-native terminal repair lane, Docker makes dependencies and tests repeatable, and tmux keeps the model, agents, tests, and operator evidence visible in separate panes. The target is a reviewable change produced on hardware the developer controls, not unattended production deployment.
It is distinct from the existing autonomous-swe-terminal-stack. That stack coordinates multiple autonomous issue-to-patch agents; this one combines two human-guided coding surfaces around one local model runtime and adds Docker as the reproducibility boundary. Use it for proprietary repositories, offline-capable experiments, regulated prototypes, or cost-controlled development where source and prompts should remain local. Offline-capable does not mean automatically air-gapped: models, container images, packages, and repositories must be fetched or mirrored before the network is removed.
Run One Local Model Service Deliberately
Start Ollama as the shared inference service and pin the exact model name, quantization, context size, and Ollama version in the project runbook. Ollama documents its local generation endpoint at localhost:11434, and both coding clients can use that local service. Cline's official local-model guide selects Ollama as the provider with the same localhost base URL and recommends focused tasks plus compact prompts. Record model pulls and checksums where available so a later run does not silently use a different model.
Local inference moves the privacy and availability boundary onto the workstation, but it also makes hardware and model capability part of the acceptance criteria. Cline's guide maps 16–32 GB RAM to small or quantized models, 32–64 GB to mid-size coding models, and more memory to larger contexts. Aider warns that weaker local models may fail to produce reliable code edits and configures context carefully to avoid silent truncation. Prove the selected model on a small repository task before trusting it with a broad refactor, and keep a cloud fallback disabled unless the operator explicitly enables it.
Separate the Editor and Terminal Change Lanes
Use Cline for repository exploration, a written plan, bounded editor changes, and interactive approval of tool calls. Configure the Ollama provider, keep auto-approve off for destructive or external actions, and begin from a clean branch or isolated worktree. The task contract should name allowed paths, expected behavior, commands that may run, secrets that must remain unavailable, and stop conditions. A checkpoint or plan is evidence for the reviewer, not permission to expand scope.
Use Aider as the terminal lane for focused edits, test-driven repairs, and Git-visible iteration. Its Ollama guide uses OLLAMA_API_BASE on 127.0.0.1:11434 and recommends the ollama_chat model prefix; its normal workflow edits named files and records changes in Git so they can be inspected or undone. Do not let Cline and Aider write concurrently to the same branch. Hand off a clean commit from one lane to the other, state the remaining failure precisely, and keep the final diff attributable to a short sequence of reviewed commits.
Use Docker for Reproducibility, Not a Security Claim
Build the project environment from a reviewed Dockerfile and Compose configuration so compilers, package managers, databases, and test services are repeatable. Docker describes containers as self-contained, isolated, independent, and portable processes; that is valuable for reproducing tests without installing every dependency on the host. Mount only the repository paths and caches the job requires, prefer read-only mounts for reference material, use disposable volumes for test data, and pin base images or digests for runs that must be reproducible.
A container is not a complete hostile-code sandbox. Containers share the host kernel, mounted paths expose host data, a Docker socket can grant broad control, and network access can still reach external services unless it is constrained. Never mount the home directory, SSH agent, cloud credentials, or production configuration into an agent-controlled container. Run as a non-root user where practical, cap CPU and memory, deny unnecessary ports and networks, and execute the final validation from a freshly built image rather than the agent's modified interactive container.
Operate the Workflow in tmux
Create a named tmux session with dedicated windows or panes for Ollama logs, Cline, Aider, Docker services, the neutral test runner, resource monitoring, and the review shell. The official tmux model groups terminals into panes, panes into windows, and windows into sessions that can be attached or detached. That layout keeps a long local-model run alive across an SSH disconnect and lets the operator inspect every lane without mixing prompts, test output, and service logs in one terminal.
Treat tmux as an operator console, not a process supervisor or audit system. Name windows consistently, print the repository path and commit at the start of each lane, and capture only non-secret command output needed for the review. Watch Ollama memory use, Docker container state, test duration, and repeated failures from separate panes. Stop the run when the same failure repeats, the model requests an out-of-scope file, the diff grows without new passing evidence, or resource pressure makes local inference unreliable.
Execute, Verify, and Choose the Right Trade-off
A safe run is sequential: establish a clean worktree; build the Docker environment; pull and smoke-test the pinned Ollama model; ask Cline for a plan and bounded implementation; inspect the diff; use Aider only for a precisely described repair; run formatting, static checks, unit tests, integration tests, and any browser suite from the neutral Docker lane; then review the final commits before merge. Keep production credentials and deployment authority outside the session. The definition of done is a reproducible patch and evidence bundle, not an agent saying the task is complete.
The software can begin at zero license cost because Cline, Aider, Ollama, Docker Engine components, and tmux have open-source or free-use paths, but the real budget varies with workstation memory, GPU capacity, electricity, model storage, Docker Desktop licensing, and any cloud-model fallback. Choose this stack when data locality, provider control, and repeatable local testing matter more than maximum model quality or turnkey collaboration. Prefer a managed or remote workflow when the team cannot maintain suitable hardware, needs centralized policy and audit controls, or requires a model that local hardware cannot run reliably.