# Guard follow-up proof audit

Audit performed 2026-10-22 20:52–20:58 UTC. Read-only source /home/ubuntu/wt/issue-9239 at [386a88ddd8](https://git.cafe/pingdotgg/t3code/commit/386a88ddd8d6e98d1527d17bd5933fe1bc70c06c). Bounded follow-up only; earlier broad proof and N2 are not relabeled as proof of this guard.

Evidence inspected: [capturer index](https://gh-file-drop-api-prod-mi5fy3sowv63ufte.pinglabs.workers.dev/f/899546625b3ebfbe/index.md), its local raw result files, public stills and recordings, and current guard/store source. No forge writes, source changes, or live T3 state access.

## Provenance and tests

Before main bundle SHA256 bb145654bb64c2723c8d645d88b73361ea0da12cfb74f416e0c2fd1f8f6b816b matches the retained baseline bundle. The recording ran archived [a0dc6d6410](https://git.cafe/pingdotgg/t3code/commit/a0dc6d6410e6e72ca836a97bc322931206d8ed75); its difference from [97d8e3e6cc](https://git.cafe/pingdotgg/t3code/commit/97d8e3e6cc61efa14ef342afe1c2d8348fd6f7d0) is only ElectronSafeStorage.test.ts. Capturer documents the earlier-source rebuild yielding the identical bundle; this is binary equivalence, not original checkout identity.

Current main bundle SHA256 b5b417930176e34b300926fcf9a35511d7fce62db340198f82b696128612abd8 matches the reported capture. I independently ran vp pack with a scratch out-dir from committed current source: its main.cjs is byte-identical by cmp and SHA256. The worktree stayed clean. Existing build warnings concern optional x11 resolution and import.meta CJS conversion; build succeeded.

My focused desktop invocation of ElectronSafeStorage.test.ts, DesktopConnectionCatalogStore.test.ts, and linuxSecretStorage.test.ts passed: 3 files, 17 tests, 3.46 seconds. This is a separate selected set from the earlier reported 13-test validation; it does not silently replace or authenticate that earlier log. An initial root-cwd invocation produced no results and was interrupted; the successful invocation used apps/desktop cwd.

## Follow-up rows

- Real locked GNOME baseline cancellation: actual registered catalog IPC returned true; raw proof records v10 and exact non-secret catalog decryption with the fixed key. Unsafe save is demonstrated, not inferred merely from backend name.
- Current existing-catalog cancellation: capturer result is DesktopConnectionCatalogStoreProtectionError / encrypt-catalog / ElectronSafeStorageEncryptError, with insecure-fixed-key cause; index records unchanged SHA256 50a3319dc307a57febab885cb0d06dea1b6e311ac2d3465efebf6f0c44be9aec.
- Current pristine save after cancellation: same typed error; capturer index records catalog absent. The raw error result agrees. This row was not independently repeated, per the single-case limit.
- Pending prompt responsiveness: capturer main result responsive=true at 5480ms and visible window; renderer result complete, body width 1100. This proves query responsiveness, not frame-rate quality.
- Unlocked GNOME: valid catalog save true, read round trip true, prefix v11, backend gnome_libsecret. Corrected valid-catalog full app/backend restart returned restartDecryptMatches=true. Plaintext hash 78a3e1617c3e73523ffa5ed4b90b2e9cc959f79c04e806944250b5007f01f389. The earlier arbitrary-string restart failure is disclosed and excluded.
- Source refusal-before-write: ElectronSafeStorage throws on Linux async v10 and maps to ElectronSafeStorageEncryptError. DesktopConnectionCatalogStore awaits encryption before UUID generation and writeDocument; typed failure prevents temporary creation/replacement. No new source defect found in this narrow guard review.

## Fresh independent native case

Only after capturer completion and independently checking 9339/3774/3775 clear and X139 socket absent, I started private DBus, Xvfb :139, Openbox, GNOME Secret Service, and current desktop with the retained isolated HOME/XDG/T3 directories. No live ~/.t3 state. Same Electron binary, gnome-libsecret backend, inspector 9339 and local backend 3774; no port/environment mismatch. Scratch rebuild matched the deployed main bundle exactly, so the original-path byte-identical bundle was launched to preserve relative resource resolution.

Locked the real login collection, called the real registered desktop:set-connection-catalog handler via main inspector with a synthetic actual-window sender id and a non-secret string, observed a real unlock prompt and pending save, and obtained a separate mainResponsive=true inspector response. Clicked the visible Cancel button. Result: DesktopConnectionCatalogStoreProtectionError, operation encrypt-catalog, cause ElectronSafeStorageEncryptError, underlying insecure fixed-key error. Existing catalog hash before and after both a9575baed331381c4c7b9c7d6b46580771c4f007c5567ef1cabcc52a97cc3d8c. This newer existing file is the capturer's valid-catalog fixture, so it intentionally has a different hash from the earlier baseline probe. No save occurred.

Independent pending-prompt screenshot versus published after frame (top 1280x900, excluding captions): 253 differing pixels; 188 above 8/255; maximum channel difference 252. All differences lie in x=744..759, y=510..533, the pointer region. No claimed zero-pixel match.

## Recordings and visual differences

Public before recording is 37 seconds; after is 30 seconds, both 1280x1020 (1280x900 framebuffer plus 120 caption pixels), video-only with no spoken narration. I inspected timed frames from both public recordings and the longer raw recordings. Public before shows prompt at 0/10s, prompt dismissed and Still connecting at 20s, connection dialog by 29s. Public after shows prompt and Still connecting through 20s and connection dialog by 29s. Actual pointer-to-Cancel action is visible in the after sequence; raw sequences show prompt dismissal. Captions agree with raw inspector results. Captions are static diagnostic narration, not product-generated outcomes, and do not themselves prove the runtime result.

The stills are NOT matched-condition comparisons. Visible differences include centered before prompt versus top-left after prompt, blank before content versus Still connecting / recovery text and Reload after, pointer placement, prompt active chrome, and caption text. Different timing/window placement explains these samples; no new render source was changed by the guard.

Independently recomputed public-still differences: 175865 changed pixels, 91761 pixels with any channel >8/255, max channel delta 255. Primary's cancel-Diff0-gain8.png matches amplified per-channel absolute difference exactly. Primary's cancel-DiffT-gt8.png matches a white whole-pixel mask for any channel >8 exactly. These are honest nonzero diffs; older fdee matched pairs remain earlier evidence only.

## Limits, cleanup, scratch

This is real storage/service/file-writer IPC with a synthetic sender, not Settings-click proof. GNOME Secret Service ran under Xvfb/Openbox/private DBus, not a full GNOME desktop compositor. No new macOS, Windows, KWallet, Wayland, or native async-unavailable fallback run: unchanged and outside this guard follow-up. The bounded matrix is storage behavior, not a new theme/viewport matrix.

Stopped every owned process group (app, keyring, Openbox, Xvfb, DBus), then stopped the isolated backend only after checking its port, cwd, and T3CODE_HOME. Verified tracked PIDs absent, ports 9339/3774/3775 clear, X139 socket absent. Worktree clean. No raw catalog, token, environment dump, keyring, or runtime-secret upload.

Own scratch: /tmp/issue9239-guard-audit (private start/stop harness, environment JSON, process records/logs, rebuilt bundles, focused-test logs, captures, timing contact sheets, computed diffs, safe report). Retained capturer inputs were read from /tmp/issue9239-cancel-save; primary diff inputs from /tmp/issue9239-followup. Only this sanitized report is uploaded.

FRICTION: Initial root-cwd test invocation needed interruption and correct desktop cwd. Inspector lacks global require, so used Node createRequire. Whole-pixel threshold mask differs from per-channel thresholding; verified the primary's intended mask exactly. None blocked the native check. No new permission request.

VERDICT: SUFFICIENT for the bounded current Linux async-v10 refusal guard follow-up. No unresolved required row. Limits above remain explicit; this does not claim full cross-platform or Settings-click verification.