Python with DevFlow: scanning, verification, isolation

DevFlow runs Python tasks in devflow/agent-universal:stable, audits requirements*.txt files anywhere in a bounded walk of the tree with pip-audit, and caps every test container at 4 CPUs and 4 GB of memory.

Manifests

requirements*.txt

Dependency scanner

pip_audit

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 Python 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 requirements*.txt files anywhere in a bounded walk of the tree and runs pip-audit when a task finishes and on recurring vulnerability polls. pip-audit resolves each file's full dependency tree, so transitive vulnerabilities surface even when only top-level pins exist. 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 python3 -m compileall -q . and python3 -m pytest. The universal image ships Python 3.11 with pip and venv from Debian bookworm. With no commands configured, the task can merge unverified, and the timeline shows it.

Isolation and limits

Caches resolve under $HOME, a per-container tmpfs, so a virtualenv or pip cache never persists into the image. 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

Fix a failing date parser. The planner reads the parser and its tests, then proposes a plan you approve. The implementer patches the function and adds a regression test in the worktree, the gate runs the repo's pytest command, and the PR shows the evidence.