Add native Windows x64 support and end-to-end verification

.github/workflows/ci.yml

@@ -6,7 +6,7 @@ jobs:
   test:
     strategy:
       matrix:
-        os: [ubuntu-latest, macos-latest]
+        os: [ubuntu-latest, macos-latest, windows-latest]
     runs-on: ${{ matrix.os }}
     steps:
       - uses: actions/checkout@v4

.plans/README.md

@@ -4,6 +4,7 @@ Handoff from the September 11, 2026 discussion. These are small implementation b
 
 ## Remaining work
 
+- [Setup and release work order](setup-and-release.md): Windows validation first, a Codex-in-T3 setup wizard, automatic worker updates, and nightly/stable releases.
 - [T3-only MCP registration](t3-only-mcp.md): keep the tools out of ordinary Codex sessions through configuration.
 - [npm distribution](npm-distribution.md): install and launch without a source checkout. Publication was deferred until real-world testing is satisfactory.
 - [Updates during monitoring](worker-updates.md): load new code while retaining active watches and pending deliveries.

.plans/npm-distribution.md

@@ -1,6 +1,6 @@
 # npm distribution and MCP launch
 
-Status: deferred until real-world testing is satisfactory. Nothing has been published by this plan.
+Status: planned after setup and platform verification. Follow the [setup and release work order](setup-and-release.md), including native Windows support and testing. Nothing has been published by this plan.
 
 ## Intended experience
 
@@ -12,7 +12,9 @@ npx --yes --prefer-online t3poll@latest mcp
 
 This is a proposed invocation. Confirm the available npm package name and publishing account first; use a scope if needed. Follow [T3-only registration](t3-only-mcp.md) when configuring Codex.
 
-`@latest` with an online check picks up releases when MCP launches. It does not update an already-running MCP process or detached worker. An explicit version can provide a fixed installation. See [worker updates](worker-updates.md) for active monitoring.
+`@latest` with an online check picks up stable releases when MCP launches. Offer `@nightly` as an explicit opt-in and preserve the selected channel. Ordinary installations should follow their channel rather than pinning the version used for setup. An explicit version can remain a troubleshooting option.
+
+Publish nightly builds automatically after checks. Trigger stable publication manually from a commit already shipped on nightly, following T3 Code's manual promotion approach. A channel change does not update an already-running MCP process or detached worker. Include [worker updates](worker-updates.md) in the release work so active monitoring survives version handoff.
 
 ## Work
 

.plans/setup-and-release.md

@@ -0,0 +1,39 @@
+# Setup and release work order
+
+Status: Windows x64 support is implemented and tested on Gideon; see [verification](../docs/compatibility.md#windows-verification). The wizard, automatic update handoff, and release workflow remain planned from the September 11 setup discussion.
+
+## Order of work
+
+1. Establish a native Windows test environment and prove the connection and worker behavior before finalizing the wizard's platform assumptions. Add a Windows CI lane. WSL tests do not establish native Windows support.
+2. Build the TypeScript `t3poll setup` wizard for Codex inside T3, reusing discovery and managed credentials. Implement Windows support alongside the shared setup code once the platform approach is proven.
+3. Implement and test automatic worker handoff during updates. Preserve active watches and pending deliveries across versions.
+4. Test packed installations on Windows, macOS, and Linux, including real T3 and fresh Codex sessions. Windows support is a release requirement.
+5. Publish nightly builds automatically after checks, with manually triggered stable releases from a commit already published and tested on nightly. Use npm trusted publishing when configured.
+
+## Windows proof
+
+Current process inspection in `src/local-process.ts` explicitly supports Linux and macOS only. Check native T3 CLI and desktop layouts, process identity and ownership, command-line decoding, home discovery, and credential issuance. Retain verification of the selected live instance before issuing credentials.
+
+Exercise executable resolution, npm command shims, spaces and non-ASCII characters in paths, PowerShell invocation, user-private credential ACLs, SQLite locking, atomic replacement, and detached worker startup and shutdown. Do not assume Unix modes or signal behavior establish Windows correctness.
+
+Use a real Windows machine or VM for installation and end-to-end checks, plus repeatable Windows CI coverage. Record exactly which T3 distributions and architectures were exercised.
+
+## Wizard
+
+Provide instance selection and custom-location fallback, resolve the selected Codex provider configuration, preview changes, preserve unrelated settings, back up changed files, support dry runs, and make reruns repair or update an existing installation without duplicate entries.
+
+Default to T3-only tool availability. Update both Codex MCP registration and the selected T3 provider's launch arguments, checking environment overrides. Keep each installation's destination separate when multiple T3 instances share Codex configuration. See [T3 scoping](t3-only-mcp.md).
+
+Default to the stable update channel, with explicit nightly opt-in. Persist the selected channel independently of the exact package version used to run setup. Do not pin ordinary installations to the setup version. An explicit version may remain an advanced troubleshooting option.
+
+Verification must not send messages or restart existing watches as a side effect. Preserve running T3 conversations and state which checks require a fresh provider session.
+
+## Updates and release channels
+
+The MCP launch command should resolve the selected npm channel on startup. A new package does not replace JavaScript already loaded by an MCP process or detached worker. Complete [worker handoff](worker-updates.md) so new code can take over monitoring safely, including when old and new MCP clients coexist.
+
+Define update timing explicitly: startup-time channel resolution is the baseline; checking for updates during an uninterrupted MCP session is a separate decision. Include failed-download behavior, stored-state compatibility, and channel switching in the design. Avoid older clients or another channel repeatedly replacing the active worker.
+
+Reference inspected: the local T3 Code checkout's `.github/workflows/release.yml` and `.github/scripts/check-nightly-release.cjs`. Its scheduler checks twice hourly, requires new commits and a six-hour release gap, and publishes nightlies to the `nightly` npm tag. Manual stable releases build the latest published nightly's commit under a stable version. T3 also supports stable tag-push releases. Adopt the tested-commit promotion approach; its exact cadence is not a requirement for t3poll.
+
+Stable publication must be explicit and must not accidentally advance `latest` from a nightly job. Preserve source-commit traceability and serialize publishers so channel tags cannot move backward due to overlapping jobs. npm distribution tags select published versions; they do not update running processes.

README.md

@@ -21,7 +21,7 @@ The [agent setup guide](docs/agent-setup.md) covers discovery, credentials, conf
 
 ## Manual setup
 
-You need macOS or Linux, Node.js 24.10+, GitHub CLI signed in, and a compatible T3 server. Build this checkout and add one MCP configuration entry. The first thread-listing or watch call finds local T3 and creates its credential. Follow the [manual steps](docs/setup.md).
+You need Windows x64, macOS, or Linux, Node.js 24.10+, GitHub CLI signed in, and a compatible T3 server. Build this checkout and add one MCP configuration entry. The first thread-listing or watch call finds local T3 and creates its credential. Follow the [manual steps](docs/setup.md).
 
 No URL or token settings are needed for a standard local installation. If multiple instances are found, select one with `T3POLL_BASE_DIR`. Choose the destination thread when registering each watch.
 

docs/agent-setup.md

@@ -4,7 +4,7 @@ Use this guide when asked to install or configure t3poll. For updates, follow [R
 
 Keep the running T3 server and ongoing conversations intact. Setup creates a credential but does not require a watch, a test message, or a T3 restart.
 
-1. Reuse an existing checkout of `https://github.com/eimexdev/t3poll`, or choose a suitable installation directory. Follow [installation](setup.md#install). Verify Node and authenticated GitHub CLI are available to the MCP process. On macOS, use an absolute Node runtime path and include the GitHub CLI installation directory in the MCP PATH when needed. A running packaged T3 desktop app is supported without installing a separate T3 CLI. Build successfully before configuring it.
+1. Reuse an existing checkout of `https://github.com/eimexdev/t3poll`, or choose a suitable installation directory. Follow [installation](setup.md#install). Verify Node and authenticated GitHub CLI are available to the MCP process. On macOS, use an absolute Node runtime path and include the GitHub CLI installation directory in the MCP PATH when needed. On Windows x64, use the absolute Node executable path and ensure `gh.exe` is on PATH. A running packaged T3 desktop app on Windows x64 or macOS is supported without installing a separate T3 CLI. Build successfully before configuring it.
 2. Add the minimal entry from [MCP registration](setup.md#register-mcp) to the Codex configuration home used by T3's provider. Preserve unrelated entries. Use absolute executable/script paths where needed. Existing explicit credentials can remain configured; they stay user-managed. A new standard installation needs no connection variables.
 3. Run [verification](setup.md#verify). `list` with `threads=true` automatically discovers T3 and creates a credential. If discovery reports multiple instances, ask the user to select the reported home and set `T3POLL_BASE_DIR`. For unsupported layouts, follow [manual overrides](setup.md#select-an-instance-or-use-manual-credentials). Do not guess the destination conversation.
 4. Verify the client exposes `watch`, `list`, and `stop` after a reconnect or new provider session. Preserve ongoing work while it loads. Report the installation directory, changed config file, and verification result. If only the CLI was tested, say that MCP verification is still pending.

docs/compatibility.md

@@ -4,7 +4,7 @@ t3poll targets the authenticated orchestration API in stock T3 Code v0.0.40. It
 
 Verified September 11, 2026 on Node 24.21.0 and Linux: the stock-release proof passed with T3 0.0.40 and a scripted Codex provider. MCP disconnected before delivery; T3 recorded the notification, invoked the provider, completed the turn, and deduplicated a repeated command. A separate read-only GitHub smoke check parsed reviews, comments, and checks from a public upstream PR. No live T3 server or real model session was used.
 
-Supported platforms are macOS and Linux with Node.js 24.10+. The implementation uses Node's built-in SQLite, the MCP SDK, and Zod. It does not require Effect or a database server. MCP uses ordinary stdio tools; Tasks and unsolicited MCP wakeups are not dependencies.
+Supported platforms are Windows x64, macOS, and Linux with Node.js 24.10+. The implementation uses Node's built-in SQLite, the MCP SDK, and Zod. It does not require Effect or a database server. MCP uses ordinary stdio tools; Tasks and unsolicited MCP wakeups are not dependencies.
 
 ## Boundaries
 
@@ -48,14 +48,36 @@ This proves the protocol and process flow without spending model tokens. It does
 
 Tested against an isolated copy of T3 `0.0.41-nightly.20260910.1507` on Linux. The proof starts MCP without URL/token configuration, discovers the instance, creates and verifies its credential, and forces credential renewal from the detached worker before a second delivery. A fresh CLI process then reuses the connection. No running user server or real model is used.
 
-Unit/process tests additionally cover simultaneous first use across processes, expired credential replacement, failed issuance/verification preserving the token, stale process state, ambiguous instances, and manual credential overrides. Discovery supports Linux `/proc` and macOS native process inspection for installed T3 `dist/bin.mjs` processes with `userdata` runtime state. Packaged macOS desktop apps use their bundled Electron runtime for credential issuance and renewal. Other layouts retain the manual connection path.
+Unit/process tests additionally cover simultaneous first use across processes, expired credential replacement, failed issuance/verification preserving the token, stale process state, ambiguous instances, and manual credential overrides. Discovery supports Linux `/proc`, macOS native process inspection, and Windows x64 native process inspection for installed T3 `dist/bin.mjs` processes with `userdata` runtime state. Packaged Windows x64 and macOS desktop apps use their bundled Electron runtime for credential issuance and renewal. Other layouts retain the manual connection path.
 
 ## macOS verification
 
-Verified September 11, 2026 on Apple Silicon with Node 24.21.0 and T3 Code Nightly `0.0.41-nightly.20260910.1507`. All 30 automated tests pass, including process discovery, paths containing spaces, symlinks, credential renewal, and worker survival after MCP exit. CI runs the suite on both Ubuntu and macOS. Intel Macs have not been tested locally.
+Verified September 11, 2026 on Apple Silicon with Node 24.21.0 and T3 Code Nightly `0.0.41-nightly.20260910.1507`. All 30 automated tests pass, including process discovery, paths containing spaces, symlinks, credential renewal, and worker survival after MCP exit. CI runs the suite on Ubuntu, macOS, and Windows. Intel Macs have not been tested locally.
 
 A read-only check of a running desktop installation discovered its server without connection overrides, issued a managed credential, and listed 142 threads through both the service and a real stdio MCP client. The MCP client exposed `watch`, `list`, and `stop`. The live installation had no watches, and no messages or watches were created there.
 
 The isolated stock proof passed against the same packaged app. It verified initial credential issuance, renewal from the detached worker, delivery after MCP disconnected, another delivery during a running scripted provider turn, turn completion, and command deduplication. No model calls were made. The proof pins the scripted provider's executable and environment because desktop startup can replace the inherited PATH.
 
 The stock proof also accepts a packaged macOS app. Use the app's executable as `T3POLL_TEST_T3_RUNTIME` and its `Contents/Resources/app.asar/apps/server/dist/bin.mjs` as `T3POLL_TEST_T3_BIN`. The proof selects only its disposable T3 home, so another running installation cannot be selected by accident.
+
+## Windows verification
+
+Verified September 11, 2026 on Gideon, Windows 11 x64 build 26200, with Node 24.19.0. All 32 tests passed both over SSH and in a non-administrator interactive user context. Linux passes its 30 applicable tests; the two native Windows tests are skipped there.
+
+The isolated stock proof passed against the npm-installed T3 CLI `0.0.40` and the installed T3 desktop `0.0.41-nightly.20260911.1551`, using disposable homes and a scripted provider. It verified automatic credentials, worker renewal, delivery after MCP disconnection, running-turn steering, and command deduplication. Real Codex CLI `0.154.0` separately verified disabled-by-default MCP tools and the T3 launch override without model calls. The npm tarball installed in a Windows directory containing spaces and non-ASCII characters and passed the npm T3 and real Codex proofs. User T3/Codex configurations and conversations were not changed.
+
+Windows x64 support uses native process inspection and Windows ACLs through the existing Koffi dependency. Process inspection checks the token owner before reading parameters. It bounds remote reads and rejects inaccessible or unsupported processes. The x64 PEB/process-parameter layout is internal to Windows and may change; failures stop automatic discovery rather than falling back to trusting the runtime file. Windows ARM64 and 32-bit Node are not supported by this implementation.
+
+Packaged desktop discovery recognizes both `app.asar` and `server.asar`. Windows Restart Manager verifies that the selected process has that home's database open before t3poll invokes its auth CLI. Managed state and credentials receive protected current-user ACLs. Token reads reject grants to other users, while allowing SYSTEM and Administrators. This also works from an elevated account whose files default to Administrators ownership.
+
+Native test fixtures use .NET console executables rather than Unix shebangs. Their child processes are contained in Windows jobs so test cleanup cannot leave scripted providers running. These fixtures require the Windows .NET Framework C# compiler; the installed t3poll package does not.
+
+To run the isolated stock proof in PowerShell against a packaged app:
+
+```powershell
+$env:T3POLL_TEST_T3_RUNTIME = "$env:LOCALAPPDATA/Programs/t3code/T3 Code (Nightly).exe"
+$env:T3POLL_TEST_T3_BIN = "$env:LOCALAPPDATA/Programs/t3code/resources/server.asar/apps/server/dist/bin.mjs"
+node scripts/prove-t3.mjs
+```
+
+For an npm-installed T3 CLI, set only `T3POLL_TEST_T3_BIN` to its `dist/bin.mjs`. To check real Codex tool scoping without a model call, set `T3POLL_TEST_CODEX_BIN` to the installed native `codex.exe` and run `node scripts/prove-codex.mjs`. This creates a disposable Codex home, verifies no t3poll tools are exposed by default, then verifies `list`, `stop`, and `watch` with `-c mcp_servers.t3poll.enabled=true`. It does not edit the user's Codex or T3 configuration. Both proof scripts accept `T3POLL_TEST_CLI` to exercise a separately installed tarball's `dist/cli.js` instead of the checkout build.