process-monitoring

process-monitoring

A minimal environment whose tasks genuinely require a persistent terminal — and therefore the tmux tool. It exists both as a reference for building tmux-dependent environments and as the end-to-end check that the local tmux reference tool (taiga-core/src/taiga/tools/tmux.py) behaves like the hosted one.

Problems

id	task	why tmux
monitor-long-job	Start /opt/long_job.py (≈40 s), monitor its progress, report the FINAL_RESULT token it prints at the end.	The job outlives any single one-shot bash call; the model has to start it in a session and re-capture the pane until it finishes.
query-status-server	Start /opt/status_server.py (a foreground HTTP server), then query http://127.0.0.1:8080/status and report the token field.	The server never exits — it must keep running in a tmux window while the model queries it from elsewhere.

Both are graded by exact match of the reported token (no LLM grading), and both tokens are deterministic functions of the per-problem --seed passed via extra_fields.

Prerequisites

• Docker
• taiga-local-tunnel installed and logged in — from the repo root: uv pip install -e local-tunnel/ && taiga-local-tunnel login (plain pip also works)

Build

cd examples/process-monitoring
docker build --build-context taiga=../../ --platform linux/amd64 -t process-monitoring -f Dockerfile .

Note the env-specific layer installs tmux in the image — the tmux tool (reference or hosted) drives the real tmux binary inside the container, so any tmux-dependent environment must install it.

Test locally

Interactively against the hosted platform via the local tunnel:

docker run -d -i --name process-monitoring-test process-monitoring sleep infinity
taiga-local-tunnel start --container process-monitoring-test \
  --metadata-file problems-metadata-local.json --problem-id monitor-long-job

Or fully locally with the mcp_client using problems-metadata-local.json (image process-monitoring), which exercises the TEST_MODE reference tools, including tmux.