Skip to content

feat: add experimental Windows MSIX runtime support - #19

Open
jiahao6635 wants to merge 3 commits into
Veath:mainfrom
jiahao6635:feat/windows-runtime-support
Open

feat: add experimental Windows MSIX runtime support#19
jiahao6635 wants to merge 3 commits into
Veath:mainfrom
jiahao6635:feat/windows-runtime-support

Conversation

@jiahao6635

Copy link
Copy Markdown

Summary

This PR adds experimental Windows Store/MSIX runtime-launch support while preserving the existing macOS behavior.

The official x64 OpenAI.Codex MSIX 26.803.5235.0 is currently offline-validated, not fully supported. It has passed manifest inspection, offline bundle patching, the complete six-label Fast profile, and portable runtime tests, but it has not completed real Windows E2E validation.

What changed

  • Allows codexfast to install on win32.
  • Adds platform-specific app discovery, compatibility keys, launch, monitoring, and cleanup.
  • Discovers the current user's OpenAI.Codex package through AppX APIs.
  • Requires the verified Store identity:
    • PFN: OpenAI.Codex_2p2nqsd0c76g0
    • Publisher ID: 2p2nqsd0c76g0
    • Signature kind: Store
    • Application ID: App
    • Executable: app/ChatGPT.exe
    • Entry point: Windows.FullTrustApplication
    • AUMID: OpenAI.Codex_2p2nqsd0c76g0!App
  • Uses the strict compatibility key win32:x64:26.803.5235+0.
  • Activates the packaged app through its AUMID with a dynamically selected loopback CDP port.
  • Validates the activation PID, start time, exact executable path, and CDP arguments.
  • Monitors the admitted executable through cancellable PowerShell/CIM queries.
  • Performs fail-closed cleanup through a native process handle after revalidating PID, start time, and executable path.
  • Requires bounded exact-path polling to confirm that no admitted-path process remains.
  • Avoids direct Node access to protected WindowsApps manifests, executables, or app.asar.
  • Does not invoke macOS launchctl, pgrep, process-group termination, or the Sparkle update hook on Windows.

Windows Fast profile

The Windows runtime profile retains the complete six-label Fast patch set:

  1. Speed setting
  2. Speed service tier allowance
  3. Speed service tier request allowance
  4. Speed service tier conversation fallback
  5. Composer Intelligence Speed menu
  6. Fast slash command

The five eager Fast labels remain required during initial interception. Speed setting is validated when its lazy-loaded Settings asset is requested.

Windows intentionally skips the macOS automatic-update targets, Plugins targets, and model-injection targets until they are separately validated on Windows.

Build, packaging, and CI

  • Adds a windows-latest CI matrix for npm and pnpm.
  • Adds Windows-safe command resolution without relying on POSIX sh.
  • Keeps the generated entrypoint portable across checkout line endings.
  • Adds Windows portable runtime, packaging, and distribution checks.
  • Adds fixed PowerShell behavior validation under Windows PowerShell 5.1.
  • Retains the full macOS runtime regression job.
  • Publishes the documentation index and fixes npm-package links to repository-only documentation.

Validation completed

The following checks pass in the current development environment:

  • npm run build
  • npm run build:check
  • npm run build:check:distribution
  • npm run typecheck
  • npm run test:windows
  • npm run check:version-drift
  • node --check bin/codexfast
  • node --import tsx test/runtime-launch-flow.mts
  • CI=1 npm_config_cache=/tmp/codexfast-npm-cache npx --yes pnpm@10.33.0 test
  • npm run test:build
  • npm pack --dry-run --json --ignore-scripts
  • git diff --check

The Windows CI job additionally runs the PowerShell 5.1 AST/C# compile validation that cannot be executed natively from the current macOS environment.

Known limitations

This remains experimental / offline-validated Windows support:

  • No real Windows E2E run has completed yet. AUMID activation, live CDP attachment, UI behavior, service_tier: "priority" request evidence, cleanup behavior, and installed-package integrity still require validation on a real Windows machine.
  • arm64 is not validated.
  • The loopback CDP listener is not kernel-level bound to the authoritative activation PID. URL, port, process identity, and command-line checks reduce risk but do not prove socket ownership at the kernel level.
  • Port allocation has a reservation race: codexfast releases the temporary listener before packaged-app activation, so another process could claim the selected port.
  • The pre-launch exact-path snapshot and AUMID activation are separate operations. Concurrent launches or another activation between those steps can still create a race.
  • AUMID activation can interact with Windows application-instance reuse semantics. Identity checks fail closed when the returned process cannot be proven to belong to this launch, but they cannot eliminate every concurrent-activation race.
  • The polling monitor cannot recover the real Windows process exit code. A normal post-readiness disappearance returns success only after exact-path confirmation; ambiguous or residual-process cases return non-zero.
  • Cleanup covers the verified app/ChatGPT.exe root and exact admitted executable path. Differently named helper processes are outside that exact-path guarantee and may require a manual full quit.
  • Snapshot-only processes are never terminated without an authoritative activation PID. If cleanup identity cannot be confirmed, codexfast reports the limitation and requires manual recovery rather than broadening termination scope.

A Windows package version must not be promoted from offline-validated to supported until the real-machine checklist is completed.

@jiahao6635

Copy link
Copy Markdown
Author

Validation update for bdff303:

  • Windows (npm): passed
  • Windows (pnpm): passed
  • Windows PowerShell 5.1 AST/C# helper validation: passed in both Windows jobs
  • Full macOS runtime regression: passed

Fork CI run: https://github.com/jiahao6635/codexfast/actions/runs/31298197535

This validates the portable Windows implementation and fixed PowerShell fragments on hosted Windows, but the runtime support remains experimental / offline-validated until the real installed-app E2E checklist is completed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant