Go with DevFlow: scanning, verification, isolation

DevFlow runs Go tasks in devflow/agent-universal:stable, audits a go.mod at the repo root with govulncheck, and caps every test container at 4 CPUs and 4 GB of memory.

Manifests

go.mod

Dependency scanner

govulncheck

Agent image

devflow/agent-universal:stable

Scan timeout

300 s per scan by default

Container caps

4 CPUs, 4 GB memory (6 GB with swap), 512 processes

How a Go task runs

You describe the task, the planner reads the code and may ask questions, and implementation starts only after you approve the plan. The plan splits into at most 8 subtasks, implemented in a git worktree on the branch devflow/<id>, then verified, summarized and opened as a PR. Agents work in the image listed above.

Dependency scanning

The scanner looks for a go.mod at the repo root and runs govulncheck when a task finishes and on recurring vulnerability polls. Only the root is checked, so a module nested in a subdirectory is not audited. Each scan stops after 300 seconds by default (SCANNER_TIMEOUT_SECONDS) and never blocks the gate.

Verification gates

Gates run only the configured test_commands, stored as bare in-container commands, for example go build ./... and go test ./.... The universal image pins Go 1.25, with go and gofmt linked into /usr/local/bin so a login shell keeps them on PATH. With no commands configured, the task can merge unverified, and the timeline shows it.

Isolation and limits

Module and build caches resolve under $HOME, which is a per-container tmpfs, so nothing is written into the image at run time. Test and build commands run in Docker as a non-root user, capped by default at 4 GB of memory (6 GB with swap), 4 CPUs and 512 processes. The agent can write only to the task worktree and its git data, toolchain paths such as /usr stay read-only, and code-writing roles reach only allowlisted hosts.

A typical task

Upgrade a module that govulncheck flagged. The planner proposes the new version and you approve the plan. The implementer edits go.mod and go.sum in the worktree, the gate runs go test ./..., and the PR body lists which checks ran.