dev-runtimes

What this is for

You know these languages. What you do not know without looking is how THIS machine is set up: which versions are installed, whether pip is allowed to write system-wide, and where a project's files are. That is what this covers — the running, not the writing.

Find out what is here before installing anything

run_command "python3 --version; go version; node --version" in one call. Three answers, one round trip. list_commands tells you what else is available without guessing.

Install through the dedicated tool — install_packages python3-venv golang nodejs npm — rather than apt through a command, and as a job if it is more than a couple of packages.

Python: the externally-managed error is not a bug

Debian 12 and later refuse pip install outside a virtualenv with error: externally-managed-environment. That is the distribution protecting its own packages, and --break-system-packages is exactly what it sounds like.

Make a venv instead:

run_command   python3 -m venv /path/.venv
run_command   /path/.venv/bin/pip install -r requirements.txt

Call the venv's binaries by path. There is no shell session persisting between your tool calls, so source .venv/bin/activate in one run_command does nothing for the next one — that is the single most common way this goes wrong here. /path/.venv/bin/python script.py, every time.

For a tool rather than a library, pipx installs it isolated and on PATH.

Go

go build and go test are usually fast enough for a plain command; a first build that downloads a module graph is a job. Two things that bite:

• GOCACHE and GOPATH need a writable home. Running as a user with none produces errors that look like permission bugs in your code.
• go run compiles every time. For anything you will run twice, go build -o once and run the binary.

CGO_ENABLED=0 go build gives a static binary, which is what you want if it is going into a container or onto another machine.

Node

npm ci when there is a lockfile — it is reproducible and it is faster; npm install when you are deliberately changing dependencies. Both are jobs on a real project.

node_modules is large: do not list_directory it, and do not read a build log into the conversation when the last twenty lines are the answer (npm run build 2>&1 | tail -20).

A dev server is a job, and you must stop it

npm run dev, python -m http.server, go run ./cmd/server — none of these return. Never a plain run_command:

job_start   npm run dev
job_status  → read the port it printed
browser_open / browser_goto  http://localhost:<port>
...
job_abort   when the task is done

Leaving it running is the failure a person has to notice and clean up. It holds the port, so the next attempt fails with "address in use" and looks like a different bug. job_list shows what you left behind; check it before you finish.

Prove it works, do not assume

A build that exits 0 has compiled, not worked. Run the test, hit the endpoint with browser_goto or run_command "curl -sS -o /dev/null -w '%{http_code}' http://localhost:PORT", and read the number. Where there is an artifact — a binary, a bundle, a page — open it and check.

Secrets belong in the environment, not in your arguments

An API key in a run_command is in the transcript forever. Write it to a .env the process reads, or have the person export it — the rule in your system prompt applies here exactly as it does everywhere else.