T3 Code runtime driver for teamai workflow steps and judges

What they did

The author added a new step runtime to teamai, `@teamai/runtime-t3` (executable `teamai-runtime-t3`), so `teamai workflow start <flow> --driver t3` runs each prompt step as its own T3 Code thread on the local machine. teamai still prepares the worktree, reads the result file, and commits and pushes on the host; T3 only runs the agent. The runtime speaks the stdio runtime protocol: `init` signs in to T3's MCP endpoint over OAuth with PKCE and a loopback redirect (unattended runs reuse a kept credential or fail `login_required`), `open` matches the checkout to a T3 project or creates a confined judge place, `prompt` calls `t3_thread_launch` with `existing_worktree` and an explicit runtime mode, `cancel` interrupts the thread, `close` stops a still-running thread or removes a judge's copy, and `reattach` finds the same thread from the journal without a second launch. Steps launch in T3's Auto mode; `runtime_mode` can only tighten it to `auto-accept-edits` or `approval-required`, and `init` rejects anything else before calling T3. Credentials are refused up front because a thread runs on T3 Code's own sign-in (`can.env: false`). For scored passes, a judge runs in a fresh thread under No project in a new scratch folder: teamai copies `confined.dir` in without symlinks, makes it read-only (0555/0444), rewrites the brief to point at the copy, and reports `finished.confined` as `{ level: best-effort, access: read }`. The author also wrote `docs/guide/runtime-t3.md` plus a zh-CN page, added a T3 subject to the prompt scenario suite, and changed one E2E assertion from `runtime_not_found` to `runtime_failed` with "T3 Code is not running". They tested with typecheck, lint, docs check, 43/43 unit tests against a fake T3 MCP server, 92 passed scenario tests, and 68/68 E2E, then ran real CLI runs against T3 Code 0.1.8-nightly on macOS with a PATH holding only node, git and teamai.

How it went

Real runs succeeded: a step settled in about 20 s with zero approvals in Auto mode, a judge settled in 16 s and returned `{"answer":{"label":"good","reasoning":"…"}}`, and cancel after a SIGKILL interrupted the thread within a second. Failures were diagnosed with clear codes: `sign_in_too_narrow`, `bad_option` for `runtime_mode: full-access` and for credentials, and `tool_failed` when the agent wrote `"failure": null`. The guide's examples come from these runs.

Worth knowing

Judge isolation is best-effort only: reads outside the copy are not blocked, file modes can be changed back by the same user, and the network is not restricted, so `isolation: verified` scorers are never judged here. A judge whose thread T3 stops answering ends `t3_unavailable` and its copy is removed even if the thread still runs. Codex on T3, `close_failed` against real T3, and Linux/Windows browser opening were not tested. A step resuming a session starts a new conversation because T3 cannot launch on an existing session. The `score[0].publish` step fails `not_initialized` without a teamai.yaml, unrelated to this runtime.

Wiring

The workflow CLI resolves `--driver t3` to the shipped `teamai-runtime-t3` binary and speaks the stdio runtime protocol version 1. `init` performs OAuth with PKCE over a loopback redirect against T3's MCP endpoint and returns `confinedPrompt: true` with `can.confined [{ level: best-effort, access: read, tools }]` and `can.env: false`. `open` either matches the checkout to a T3 project or, for a judge, creates a confined place. `prompt` for a step calls `t3_thread_launch` with `existing_worktree`, an explicit `runtimeMode`, and `clientRequestId` set to the operation, then `t3_thread_wait` until the result file and session are available. For a judge it launches a scratch idle thread, copies `confined.dir` in read-only, sends the brief via `t3_thread_send`, and reads the last reply as JSON. `cancel` calls `t3_thread_interrupt`, also after the driver died via the journal. `close` stops a running thread or removes a judge's copy. `reattach` reads the journal to reuse the same thread. The package adds `@modelcontextprotocol/sdk` ^1.32.2, plus additive `bin` and tsup entries.

Try it yourself

Add a T3 Code step runtime to this repo's workflow engine, following the existing runtime protocol. Create a package `@teamai/runtime-t3` with executable `teamai-runtime-t3` that speaks the stdio runtime protocol: `init` signs in to T3's MCP endpoint via OAuth with PKCE and a loopback redirect, reusing a kept credential for unattended runs and failing `login_required` otherwise; `open` matches the checkout to a T3 project, or creates a confined judge place; `prompt` calls `t3_thread_launch` with `existing_worktree` and an explicit runtime mode (Auto by default, `runtime_mode` may only tighten to `auto-accept-edits` or `approval-required`, reject anything else in `init`); `cancel` calls `t3_thread_interrupt`; `close` stops a running thread or removes a judge's copy; `reattach` finds the same thread from the journal. For judges, copy `confined.dir` into a fresh scratch folder without symlinks, chmod it read-only, rewrite the brief to point at the copy, and report `finished.confined` as best-effort read. Refuse `NAME: env:VAR` and `<tool>: login` with `credentials_unsupported` since `can.env` is false. Wire `--driver t3` into the workflow CLI, add a T3 subject to the prompt scenario suite, and write `docs/guide/runtime-t3.md` with a zh-CN page. Run typecheck, lint, docs check, unit tests against a fake T3 MCP server, and the E2E driver suites.