# Proof audit, pass 1

Read-only evidence audit for [#32950](https://git.cafe/pingdotgg/t3code/pull/32950), branch `fix/issue-32938`, requested local head [c25810b9db](https://git.cafe/pingdotgg/t3code/commit/c25810b9db2db407fd8470056a277d14f0177988). No new runtime capture was requested or produced in this pass. No checkout edits, pushes, comments, servers, or worktrees were made.

The inspected checkout was clean at the start. During final reporting, another process advanced it to [db9f0faa91](https://git.cafe/pingdotgg/t3code/commit/db9f0faa91e4cfdd62af3ace9c2d42ffae517340), a test-only change making the symlink fixture relative; the production modules are identical. This audit and its test results stay scoped to the requested head, including its absolute symlink fixture. The forge still reported pushed head [cb11eca98a](https://git.cafe/pingdotgg/t3code/commit/cb11eca98a17b174f6490ed1e137b28be510b9c5), as anticipated by the brief; its CI is not evidence for the requested local head. The comparison uses local `origin/main` [ca796d5211](https://git.cafe/pingdotgg/t3code/commit/ca796d52119592de771d8ccfa955d70dba84d11e), which is merged into the requested head.

**Result: insufficient runtime proof.** Capture R1–R8 and E5 at the final agreed head. R1 should use a relative local command, so it also supplies the integrated launch proof for E2. The executable-resolution regression in E7 is already proved by a failing-on-main unit test; it does not require a separate package-install transcript. Windows rows remain explicitly `cannot-verify windows` and are not satisfied by Linux tests or captures.

## Evidence matrix

`B` means `<base-dir>/userdata/acp-registry/background-cwd`; `P` is the synthetic project workspace; `H` is the synthetic server process directory. Keep these three different. Runtime requirements concern actual child `process.cwd()` and, where applicable, ACP request `params.cwd`, not merely a resolver argument. Rows share a capture when their observable conditions overlap; no Cartesian product of every executable and every spawn site is required.

| Row / case | Runtime path and expected observable result | Unit evidence and whether it fails on main | Existing PR transcript | Required final-head proof / reproduction |
| --- | --- | --- | --- | --- |
| R1 — POSIX startup: status probe and sign-in discovery | Driver passes B to both paths. Discovery initializes only; the status probe initializes and creates its test session with `sessionCwd=B`. Both children spawn in B, each holding 1 directory watch rather than H's 1,666. | `driver.test.ts`: **starts background discovery and sign-in agents outside the server's directory** fails on main and passes here. It intercepts two catalog resolutions, fails before spawning, and checks their directories exist and are empty. It proves neither actual child cwd nor watch count nor which of the two calls is which. | After [1132ec433b](https://git.cafe/pingdotgg/t3code/commit/1132ec433bf8fc2e9fcfc45a31b8233845ceab4a) shows two spawns, B, both watch metrics=1, and one `session/new` in B. Before/control establish tree vs empty-directory watch counts. Startup-only `session/new` is a probe, not a project thread. | **Capture required.** Run the local stub with a relative commandPath using recipe A. Add initialize/clientInfo logging to distinguish probe from discovery. Show final SHA, both process cwd/watch counts, and the probe's session cwd. This can cover E2 at the same time. |
| R2 — POSIX sign-in initialization and agent/env-var verification | `auth.authenticate` starts an ACP runtime in B. Agent-managed sign-in uses `authenticate` then `session/new` in that runtime; env-var sign-in skips `authenticate` and verifies in the same runtime. These share the changed auth cwd. | `auth.test.ts`: **discovers methods without signing in, then waits for browser consent and session verification** and related verification tests use a supplied fake runtime. They pass without this PR and do not prove driver-to-process cwd. | Not covered: advertised methods are empty and no sign-in RPC occurs. | **Capture required.** Recipe B, advertise a synthetic agent auth method and call `provider.auth.start`; log initialization, authenticate, verification `session/new`, B and watches=1. Env-var verification shares this runtime/cwd; no separate cwd capture is needed for it. |
| R3 — POSIX terminal login / PTY | `runTerminal` launches `resolved.spawn.command` plus distribution/local args and terminal-method args through `PtyAdapter.spawn`, with cwd=B. This is a separate spawn mechanism. | `auth.test.ts`: **runs terminal auth directly with the resolved environment and reconnects to verify** asserts a fake PTY gets the supplied `/workspace` cwd. It passes on main and never establishes driver supplies B. | Not covered; the original stub has no terminal method or login mode. | **Capture required.** Recipe B, advertise terminal auth, implement a login argv mode in the stub that logs cwd, watches and argv and exits 0. Use `provider.auth.start`. Show actual PTY child in B, watches=1, expected login args and exit 0. |
| R4 — POSIX post-terminal-login verification | After PTY exit, auth creates a new ACP runtime, then `start()` creates a session. Both actual process cwd and session request cwd remain B. | Same terminal-auth unit test proves reconnect sequencing with fake runtimes, not the changed driver's real spawn cwd; passes on main. | Not covered. The old startup probe's `session/new` is not post-login verification. | **Capture required.** Continue R3 and show a new PID after successful PTY exit, `processCwd=B`, watches=1, `sessionCwd=B`, and successful auth-flow completion. |
| R5 — POSIX auth-controller logout | `auth.logout` resolves and starts a fresh runtime in B, initializes and sends logout. Public `provider.auth.logout` and normal `server.logoutAcpRegistry` reach the controller. | No failing-on-main test covers actual logout child cwd. The startup resolver test does not invoke logout. | Not covered. | **Capture required.** Recipe B, advertise logout capability and log the logout method. Call `provider.auth.logout` or `server.logoutAcpRegistry`; show its child in B, watches=1, logout response and completion. |
| R6 — POSIX background directory persistence | `makeDirectory(B, recursive:true)` creates a stable state-directory path, reused on another driver/server start. It does not clean arbitrary agent-created files. | Startup test asserts empty directories before spawn only, without restarting. No restart regression test. | Prose says B exists and is empty after SIGTERM and is reused across restarts. No filesystem transcript or second startup is shown. | **Capture required.** Recipe A, stop by tracked PID, record B exists and an empty directory listing; restart the same base, show both spawns still use B with 1 watch, stop and list B again. Do not claim the code enforces emptiness for arbitrary agents. |
| R7 — POSIX real thread session stays in project | `adapter.ts` resolves using `input.cwd`; the ACP runtime receives the caller's runtime input and resolved spawn. No substitution of B. For a thread in P, process cwd and `session/new` cwd must both be P. | No added failing-on-main test covers this compatibility path. Catalog tests retaining `/workspace` are not real thread sessions. | Not covered. Every shown `session/new` belongs to startup, in H before and B after. | **Capture required.** Recipe C, create a project rooted at P, create a thread and send a turn over the server RPC with this synthetic provider. Show a separate actual ACP process in P, `sessionCwd=P`, expected project-directory watch count, and a completed prompt response. |
| R8 — POSIX session-management calls keep caller cwd | Driver list/delete sessions and list/set/disable configurable providers pass their caller's cwd into the shared management runtime. Management `logout(cwd)` also retains its caller cwd. None switches to B. | No added failing-on-main test proves actual management child cwd. | Not covered. | **Capture required for the shared management runtime.** Recipe D: call `server.listAcpRegistrySessions` for P; show management clientInfo, actual process cwd=P, request cwd=P and a valid response. All listed management operations share the same factory, so this one runtime capture covers their cwd. The internal management logout fallback takes its supplied cwd (the legacy WS fallback supplies server config cwd); ordinary registry logout instead uses R5. Do not relabel it as a project logout. |
| E1 — POSIX local absolute command / bare name resolving absolute | Local resolution uses effective PATH, anchors the resolved executable, validates it, returns it with requested child cwd and `shell:false`. An already absolute command is unchanged. | **resolves a local executable path and inherits the host environment** and **resolves a local command on the selected environment without the registry** cover absolute executable and PATH-name outputs, args, env and cwd; both are main-passing controls. | The After capture uses a relative command; Before setup does not disclose commandPath form. | **No separate capture required:** unchanged absolute-path behavior is covered by existing unit controls plus the shared actual spawn in R1. If captured, change only commandPath to the stub's absolute pathname and expect B/1 watch. |
| E2 — POSIX relative local commandPath | Relative executable is anchored to the Node process cwd, independent of requested spawn cwd B or P. | **launches a relative local executable regardless of the spawn cwd** fails on main and passes here. It asserts absolute output and same file via realPath; despite its name, it does not execute the command. | After explicitly says relative commandPath and shows successful startup from B. The actual relative value and resolved command are not logged. | **Resolution regression satisfied by unit test.** Include actual relative settings value and executable identity in R1's final-head capture; no separate run is needed. The relative base is process.cwd(), which may differ from configured server cwd. |
| E3 — POSIX symlink then `..` | POSIX anchoring preserves traversal semantics and does not lexically normalize a path to a decoy. Absolute commands remain untouched; relative commands gain only a cwd prefix. | **launches the executable that `..` after a symlink resolves to** passes on main and here. It reads target content; it does not launch. The configured path is absolute, so it guards a naive normalization rewrite but does not directly test the relative-prefix branch. | Not covered. | **No extra transcript required for this main-preserving control.** Unit plus direct inspection proves no normalization was introduced. Optional reproduction: point `link` at `actual/child`, put different agents at `actual/agent` and root `agent`, configure `link/../agent`, and log the actual agent identity. Do not claim this POSIX case proves Windows reparse semantics. |
| E4 — POSIX registry absolute override | With source=registry and commandPath set, use the override executable while retaining registry distribution args/env, not local commandArgs. Already absolute path is unchanged. | **resolves command overrides while preserving registry args and environment** is a main-passing control; it uses an absolute commandPath. | Not covered by a local-source provider. | **No separate capture required** for absolute preservation; existing unit covers it. Recipe E5's relative override capture also exercises the registry branch and retained distribution args/env. |
| E5 — POSIX relative registry override | Override resolution now anchors a relative executable against process cwd before spawning in B/P, retaining registry args/env. This is a distinct branch from local commands. | Existing override test is absolute. No failing-on-main test covers a relative override. E2 tests only source=local. | Not covered; After source=local cannot establish the registry-override branch. | **Capture required.** Recipe E: use a registry entry and relative commandPath pointing at the stub. Show source/entry/relative value, successful actual child in B, watches=1, expected executable identity, and retained distribution args/env. |
| E6 — POSIX npx/uvx managed executable already absolute | Both package kinds prepare/discover their exposed command and now anchor it before returning spawn info. An already absolute path stays unchanged. Package-manager/install helper processes keep their prior cwd behavior; this PR relocates agent processes, not every npm/uv subprocess. | **installs into T3 home a package and launches its exposed command** (npx) and **uses its managed prefix despite a system-owned npm prefix** cover absolute managed paths, preferred PATH and installation reuse; main-passing controls. Shared helper covers uvx anchoring as well. | No package-source runtime evidence. | **No separate runtime required** for the no-op absolute input branch. Recipe F can be used if desired, with fake package managers and the stub in a managed bin directory. Do not require real package installation to prove a string-preserving branch. |
| E7 — POSIX npx/uvx executable found through relative PATH | Both kinds share the same `anchorToProcessCwd(installed.executablePath)` call. A fallback exposed command found via relative PATH becomes absolute before any cwd change can affect its lookup. | **launches a global package found through a relative PATH entry by absolute path** fails on main and passes here. Uses uvx plus a controlled executable resolver returning a relative result and asserts absolute/same-file output. npx/uvx share the changed call; npx discovery has separate main-passing controls. | Not covered. This anchoring line was added after the recorded After head. | **Resolution regression satisfied by the failing-on-main test; no separate runtime required.** It is not proof of a real relative-PATH launch or of native Windows behavior. Optional recipe F must leave the managed candidate absent and put the stub in a relative provider PATH entry so the fallback is genuinely selected. |
| E8 — POSIX binary distribution without override | `installBinary` returns the managed cache executable. Its resolution branch is unchanged; all driver-owned agent spawns still adopt B. | **installs and reuses a registry binary in the managed cache**, **requires a regular executable file in the managed binary cache** and existing safety tests are main-passing controls. | No binary-distribution runtime evidence. | **No separate capture required** for unchanged binary installation/resolution. Optional recipe F: seed a synthetic cached binary containing the stub; show managed absolute command and B/1 watch. Do not replace this branch with commandPath and call it a binary-install test. |
| W1 — Windows cwd routing, PTY and persistence | Same status/auth cwd substitutions and unchanged thread/management routing as R1–R8, using Windows paths and processes. Native filesystem watcher counts are not Linux inotify counts. | Driver/terminal tests run on this Linux host. No native Windows process/PTY/restart capture. | Explicitly not checked. | **cannot-verify windows.** A Windows host must run A–D with Windows executable fixtures, path/cwd observations and appropriate watcher metrics. Never claim `/proc` or Linux inotify evidence applies. |
| W2 — Windows absolute, ordinary relative, drive-relative and root-relative anchoring | Local command, registry override and npx/uvx package outputs all call `NodePath.win32.resolve`. Absolute drive/UNC inputs, `tools\\agent.exe`, `C:tools\\agent.exe`, and `\\tools\\agent.exe` have different resolution contexts. | **launches a drive-relative Windows executable from the drive it was validated on** fails on main and passes here, but mocks platform and resolver on Linux. It asserts only a C-drive absolute string. **honors an exact Windows PATH override when launching a global package** is another simulated main-passing control. No native ordinary-relative/root-relative/UNC execution proof. | Explicitly not checked. | **cannot-verify windows.** Run native launch tests on the validated drive, including another child cwd/drive; record validated and actually executed target identities for all forms. The drive-relative string test does not close these native cases. |
| W3 — Windows reparse/symlink followed by `..` | `win32.resolve` lexically normalizes these components. Whether validation and spawn select the same executable needs native Windows proof with a target and decoy. | The POSIX symlink test and mocked Windows drive string test do not exercise Windows traversal. An existing changes-requested review raises this case; this audit does not claim native confirmation or dismissal of it. | No coverage. | **cannot-verify windows.** Native test with link→actual/child and different actual/agent.exe vs root/agent.exe; prove the actual launched executable. Treat the existing review separately from sufficiency of the POSIX transcript. |

## How to reproduce the capture rows

**A — isolated startup and restart.** Check out the final agreed source head and record `git rev-parse HEAD`. Within the capture worker's scratch directory create sibling directories `fakehome`, `project`, `bin`, `base` and logs; make `fakehome` contain 1,666 total directories, below the stub's 2,000 watch cap. Put the PR body's stub in `bin`, make it executable, and record the tree count. Start the checkout's source server from `fakehome` with `T3CODE_DEV_SEED=0 node /absolute/checkout/apps/server/src/bin.ts serve --base-dir /absolute/scratch/base` (or a `t3 serve` binary demonstrably built from that SHA). Keep the base and log outside the indexed tree.

Before startup, place the following local instance in `base/userdata/settings.json` (merge only into this fresh sandbox's settings):

```json
{
  "providerInstances": {
    "proof-acp": {
      "driver": "acpRegistry",
      "enabled": true,
      "environment": [
        { "name": "STUB_ACP_LOG", "value": "/absolute/scratch/spawns.ndjson", "sensitive": false }
      ],
      "config": {
        "source": "local",
        "commandPath": "../bin/stub-acp-agent.mjs",
        "commandArgs": [],
        "enabled": true
      }
    }
  }
}
```

The absolute STUB_ACP_LOG is essential: the stub's default `./spawns.log` would populate B and invalidate the emptiness assertion. Its parent must exist. Extend only the synthetic stub's diagnostics to log argv, script identity and initialize clientInfo; leave protocol stdout clean. Separate `processCwd`, protocol `sessionCwd`, watcher count and Linux `/proc/self/fdinfo` inotify count. Stop/restart the same base using the captured server PID and actual process completion, with directory listings before and after. A brand-new base is needed only at the beginning, not between the persistence observations. Do not target live T3 state.

**B — auth flows.** The PR's stub as published advertises `authMethods:[]` and has no terminal-login mode or logout capability; it cannot reproduce R2–R5 unchanged. Add synthetic agent and terminal methods, initialize capability `auth.logout`, log/answer `authenticate` and logout, and implement the terminal login argv mode before its readline loop. The login mode should log, close its synthetic watchers and exit 0. Use server RPC `provider.auth.start` for each advertised method, `provider.auth.subscribe` to observe milestones, `provider.auth.respond` if the synthetic method needs interaction, and `provider.auth.logout` for logout. Log completion rather than inferring success from a single spawned child. Watchers/logs must leave B empty.

**C — real thread.** Add project P through the server's project RPC, create a thread selecting the sandbox provider, and send its first message over the server RPC (for the current contracts, `orchestration.dispatchCommand` with `thread.create` and `message.dispatch`; use current schemas and returned provider model list). Extend the stub to log `session/prompt` and return a valid completed prompt result. This is synthetic traffic and launches no real provider. Show process/session cwd=P, distinct from H/B, and the turn's successful result. An initial startup probe alone cannot satisfy this row.

**D — management.** Extend the stub's initialize session capabilities to support list (and other operations if exercising them) and return a valid empty `session/list` result. Call `server.listAcpRegistrySessions` with instanceId and projectId for P. Its server handler supplies `project.workspaceRoot`; log clientInfo and all management request params to correlate the actual management process. List/delete sessions and list/set/disable provider calls share `makeAcpRegistryManagementRuntime`; a cwd capture at that factory covers their common route. The internal logout fallback is not normally reachable while this driver's auth controller exists; its unchanged cwd forwarding is source coverage, not an observed public logout run.

**E — registry override.** Local-source settings do not reach this branch. In the fresh base use a synthetic valid registry entry in `base/caches/acp-registry/registry.json` (the catalog's cached-index load path), with a compatible distribution and recognizable harmless args/env; use source=registry, its agentId and relative commandPath to the same stub. If a refresh could replace the fixture, arrange a deterministic cached/offline catalog setup and disclose it. Do not mutate an installed/global registry. Keep the executable override set: this proves the override branch, not installation of the advertised distribution.

**F — optional distribution captures.** Reuse synthetic npm/uv manager behavior from `AcpRegistrySupport.test.ts` and its `testing/*.fixture.sh` files, configuring the provider PATH and isolated managed roots. Make the selected exposed executable the ACP stub. For relative fallback, ensure the preferred managed bin does not already satisfy resolution and record the actual relative PATH entry. For an unoverridden binary, seed the sandbox's compatible cache or serve a synthetic archive through an isolated catalog fixture; do not use commandPath to bypass installation and then claim binary-path coverage. These cases are optional because their changed resolution regression or unchanged control already has unit evidence; do not expand the required runtime capture into real package downloads.

## What changed after the existing capture

The After capture is explicitly bound to [1132ec433b](https://git.cafe/pingdotgg/t3code/commit/1132ec433bf8fc2e9fcfc45a31b8233845ceab4a), not the audit head. Its startup cwd substitutions and local/registry override anchoring are unchanged at this head, so it remains useful historical evidence for R1/E2, but is not a final-head integrated transcript. [d3f60d440d](https://git.cafe/pingdotgg/t3code/commit/d3f60d440d) subsequently anchored package executables (E7), and merged main changed status-probe environment handling to add `MISE_OFFLINE=1`. Merged command-discovery changes also affect probe output, though not cwd selection. The final test-only commit changes the Windows drive-relative assertion. Therefore repeat R1 against the final agreed head; E7's new behavior is covered by its main-failing unit test rather than by the old transcript. R2–R8/E5 need first captures, not merely a retimestamped copy. The Before tree/empty-directory controls remain valid historical controls and need not be repeated solely for SHA freshness.

## Checks performed and limits

- Requested-head focused run: `vp test run packages/provider-acp-registry/src/server/AcpRegistrySupport.test.ts packages/provider-acp-registry/src/server/driver.test.ts`: **2 files / 48 tests passed**.
- Main counterfactual: a scratch-only Vite load plugin substituted the two production modules from local `origin/main` into the current five added test cases, keeping the checkout untouched. **4 failed / 1 passed**: startup cwd, local relative anchoring, simulated Windows drive-relative anchoring and package relative-PATH anchoring failed for their intended assertions. The absolute POSIX symlink case passed. This is a targeted production-module overlay, not a full main-checkout suite run.
- Read full changed source/test diff, auth spawn paths, shared ACP process/session runtime, adapter, management runtime and RPC routing, PR body and existing review feedback. No native Windows/macOS run or new integrated runtime capture. Linux inotify proof must remain labeled Linux/POSIX; macOS shares the POSIX anchoring branch but has no `/proc` inotify transcript here.
- No repository-wide checks were run. The shared checkout subsequently advanced as disclosed above; no changes were made by this auditor. Scratch logs and the read-only overlay remain only in the allocated audit scratch directory. The checkout remains clean. No server or worktree cleanup is outstanding.

FRICTION:
brief | The published stub cannot exercise auth, PTY login, logout, a completed thread turn or management capabilities, so it is only a startup reproducer as written. | Supply the expanded synthetic protocol fixture and RPC driver for the capture pass; recipes above identify the required extensions.
other | Another process advanced the shared checkout during final reporting; only the symlink test fixture changed. | Freeze the shared checkout during an audit, or provide an immutable snapshot; this report remains pinned to the requested SHA.
infra | No native Windows execution is available; simulated path tests cannot establish Windows reparse-point traversal or PTY behavior. | A Windows host with real executable/link fixtures; retain `cannot-verify windows` meanwhile.

VERDICT: INSUFFICIENT R1 R2 R3 R4 R5 R6 R7 R8 E5