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.
| 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.
- Docker
taiga-local-tunnelinstalled and logged in — from the repo root:uv pip install -e local-tunnel/ && taiga-local-tunnel login(plainpipalso works)
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.
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-jobOr fully locally with the mcp_client using problems-metadata-local.json
(image process-monitoring), which exercises the TEST_MODE reference tools, including tmux.