# Capture notes Manual proof for [#24100](https://github.com/pingdotgg/t3code/pull/24100). Base: [eb14ddb799](https://github.com/pingdotgg/t3code/commit/eb14ddb79924a6cbcb6c26d1b97c9816c9732c55), the requested merge-base. Head: [ea14a6b114](https://github.com/pingdotgg/t3code/commit/ea14a6b114f7a389881c727feb4d7c6d214b17d2). ## Environment and configuration Linux Electron desktop, Electron 44.10.1, Xvfb via headless-desktop, Playwright Electron automation, light theme, 1440 x 1000 renderer viewport on both sides. The scenario runner cannot create this desktop IPC route and installed OS service from project/thread seed commands, so the comparison used two real app worktrees. Both desktop builds and both Vite processes sourced the same staging T3 Connect configuration. Both builds ran `T3CODE_DEV_SEED=0 vp run build:desktop`; both web clients ran `vp dev` with separate local ports. The public configuration fingerprint was 3916d1bf7993811bf04b364b5f5760a1504b976f741c0477aeecb4faacfb5b1b on both sides. Both comparison captures are signed in to the same staging account. No production relay or production account was used. Each app initialized its own task-local database at its own migration level. No live database was copied, no provider history was imported, and no projects or threads were needed for this connection-only reproduction. Rehearsals reused that side's isolated state; the compared route began as the same sole T3 Connect route, and remote SSH launch state was removed before each comparison run. SSH uses a dedicated synthetic Linux user on loopback, real OpenSSH, a real systemd user manager, and a task-only key. The external service was installed with the published T3 0.1.10-nightly.20261113.4643 executable using `T3CODE_HOME=~/.config/t3 t3 service install`. Its unmodified generated ExecStart invokes `t3 __service-launcher`; there is no ExecStart override. The supported service.env file supplies staging public config and port 18410. T3 Connect headless device login, approval in the staging Clerk instance, and `t3 connect link --headless` were completed. The app added that environment from T3 Connect and connected over the relay before adding SSH. Direct HTTP pairing was not substituted for this prerequisite. For the SSH-launched CLI, each development desktop sets T3CODE_DEV_REMOTE_T3_SERVER_ENTRY_PATH to its own commit's apps/server/src/bin.ts. This is the built-in development runner, using real source CLI execution, SSH launch scripts, credential stores, HTTP and WebSocket authentication. Neither side uses a fake helper or mock service. ## Identical comparison interaction The actual shared Playwright snippet is drive-route.js: open Add route on the existing environment, select SSH, enter 127.0.0.1 and synthetic username t3proof24100, retain port 22, and submit. Both started with no ~/.t3 home on the SSH host and the same custom-home external service and environment identity. Base displays: "That host reaches [redacted], a different machine. Add it as its own environment instead." Its runtime capture shows the original published service still active on port 18410, plus a second managed server (PID 190072, port 3774) in the default home. The custom-home ID is e4710c88-6d41-48c1-9548-b0842e2e1fe4; the default-home ID is bffcf9e2-18da-4861-b414-49f787c40634. Head displays Connected via SSH and retains the T3 Connect route on the same environment. The head runtime capture shows external adoption, port 18410, selected home ~/.config/t3, and no default-home server runtime. After removing the SSH route in the UI, T3 Connect stays Connected. Both runtime screenshots show the same service launcher PID 186648 and server PID 186661, so survival after disconnect is backed by terminal captures, not only notes. The before-relay-prerequisite still shows the base's T3 Connect route connected after the rejected SSH addition; it is the unchanged existing route, not the wrongly launched default-home environment. ## Supplemental head paths With the published service stopped, adding the SSH route launches a managed source server in ~/.config/t3, keeps environment ID e4710c88-6d41-48c1-9548-b0842e2e1fe4, and authenticates successfully. head-managed-runtime.png shows systemd inactive, managed PID 181051 in the custom home, and no default-home runtime. managed-verified.mp4 is a repeat recording of this same service-stopped launch condition. While that managed PID 181051 was still running, the remote shell's explicit T3CODE_HOME was changed to ~/.config/t3-other. launch-remote.mjs calls the actual exported production SSH launch function over real SSH, with the desktop's existing launcher ID; it uses no test harness or fake process. The head-home-change terminal capture shows the refusal to change homes, the unchanged PID and recorded original home, and no other-home runtime. This explicit-environment override exercises the managed home-change guard; changing the installed service unit itself was not exercised. ## Capture handling and scripts Magenta rectangles redact only machine-name text in the captured pixels. The unrelated staging environment was not modified. No app DOM or business behavior was changed for redaction. The final capture helper checks identical screenshots before and after reading redaction bounds, avoiding a dialog-transition race. Each final still was accepted only after two identical screenshots 500 ms apart. Videos are sampled app screenshots with measured frame intervals preserved in the MP4 timeline. Every uploaded still and all frames of each uploaded video were visually inspected. The JavaScript snippets run in a Playwright context with app (the Electron renderer Page) and ctx (shared scratch state). PROOF_DIR is the output directory. privacy-capture.js supplies capture; record-start.js and record-stop.js save timed frames; still.js checks stability. runtime-check.sh runs read-only real SSH/systemd/runtime-file queries. launch-remote.mjs requires APP_CHECKOUT, LAUNCHER_ID_FILE, REMOTE_HOME and SSH_AUTH_SOCK. home-change-demo.sh prints the guard result and checks that the existing managed PID and home remain. No credentials, private machine names, or internal checkout paths are included in these uploaded scripts. ## Scope Non-Linux service-home discovery was not exercised: these captures use Linux/systemd, not macOS launchd or Windows Task Scheduler. The active managed-home-change capture uses an explicit shell environment change rather than reinstalling the service at another home. Work performed with GPT-6.1-sol in the Codex harness. No commits or forge writes were made.