app

Codex

Public Made by Adom

by adom

Codex in Adom Hydrogen: ecosystem setup, dock dashboard and live engineering demos.

codexhydrogenastrakicaddeveloper-toolsfusionpcb
Overview Files Skills Discover Packages Releases Dependencies Issues3 Breadcrumbs Pull Requests Activity
Open general

codex_desktop_install {acceptAgreements:true} still cancelled by winget on a fresh box: msstore source agreements not accepted (exit 0x8A150046); send --accept-source-agreements too and echo the winget args

John Lauer · 27d ago

Fresh Windows 11 (Azure winvm, ab 2.1.76, codex bridge 0.1.1 dev-pinned, deployed from arav-rog's cache per DESKTOP-BRIDGE.md), 2026-09-08 16:24 to 16:26 UTC.

  1. codex_desktop_install {} -> job complete, errorCode: blocked_on_user, blockedBy: "Microsoft Store package agreements", stdout: the msstore source agreements text. Correct behaviour, the hint says to re-run with acceptAgreements:true after the user agrees.
  2. codex_desktop_install {acceptAgreements:true} -> job complete, errorCode: install_failed, winget exit -1978335162 (0x8A150046, APPINSTALLER_CLI_ERROR_SOURCE_AGREEMENTS_NOT_ACCEPTED), stdout:
The `msstore` source requires that you view the following agreements before using.
Terms of Transaction: https://aka.ms/microsoft-store-terms-of-transaction
The source requires the current machine's 2-letter geographic region to be sent to the backend service to function properly (ex. "US").

One or more of the source agreements were not agreed to. Operation cancelled. Please accept the source agreements or remove the corresponding sources.

So acceptAgreements:true is not reaching winget in the form the msstore source wants. On a box whose msstore source was never used, winget needs BOTH --accept-source-agreements and --accept-package-agreements on the install command (and --disable-interactivity so it does not wait on a prompt that nobody sees); accepting only the package agreements leaves the source gate closed, which is the text above. The job result does not echo the winget command line, so I cannot see which flags were sent; please include installer.args in the result for the next person.

Expected on a fresh box: with acceptAgreements:true the Store package installs (UAC or Store sign-in prompts aside, which _beforeUac already narrates). Observed: cancelled before download.

Deployment note for the record: bridge_list on the fresh VM shows codex 0.1.1 running from the cache with the dev pin; codex_status/readiness/describe answer once the shell grant is in place.

3 Replies

John Lauer · 27d ago

More from the same fresh VM (2026-09-08 16:27 to 16:31 UTC), for whoever fixes this:

  • A direct winget on the box with BOTH flags installs the real package in 59 s: winget install --id 9PLM9XGG6VKS --source msstore --accept-source-agreements --accept-package-agreements --disable-interactivity --silent -> Successfully installed, Get-AppxPackage shows OpenAI.Codex_26.901.6511.0_x64__2p2nqsd0c76g0, and codex_status then reports desktop.installed true with the right family. So the box is fine; it is the bridge's flag set.
  • Do not find the package by name: winget search Codex --source msstore returns Codex Vitals / CodexApp Pro / a QR app and NOT OpenAI's (I installed Codex Vitals by mistake that way and removed it). OpenAI's listing is named ChatGPT, id 9PLM9XGG6VKS, PackageFamilyName OpenAI.Codex_2p2nqsd0c76g0; search by id or by publisher OpenAI.
  • After the install, codex_desktop_open launched the app (codex_status shows the ChatGPT.exe window, hwnd 591120, and the sign-in window is on screen) but the job ended errorCode: desktop_inventory_failed. On a fresh install the first window is the ChatGPT sign-in window, which the inventory step apparently does not recognise; the open itself succeeded.
  • Sign-in is the human step from here (no OpenAI session on a fresh VM).
John Lauer · 27d ago

Testing moved to crr (ConfRoomROG), per John; arav-rog was not touched. Candidate fixes are in PR #5, source commit 9fee13e76e1f382d36bfdb924a090abbd4d8c2fe.

Bridge 0.1.2 now sends both Store agreement flags only with explicit acceptance, exposes installer.program/args, retains installer output when post-install inventory fails, and retries transient launch observations without reactivating the app. Unrelated installer errors are no longer mislabeled as missing consent.

Verified: 19 Linux tests and 17 Windows unit tests executed on crr; both-target Clippy and Windows release build pass. AB 2.1.78 on crr runs the dev-pinned candidate; deployed hashes match. Live non-accepting install correctly stops at package agreements (exit -1978335167), returns exact args, and leaves Desktop absent.

Pending user acceptance of Store source/package agreements for crr. Successful install, actual first launch/sign-in, desktop chat and plugin tests are not yet verified there. Startup recovery tests inject transient errors; the original PowerShell inventory failure cause is still unconfirmed. Leaving this issue open and PR unmerged. Detailed evidence: docs/CRR-DESKTOP-SETUP-TEST.md on the PR branch.

John Lauer · 26d ago

PR #5 is now merged into main as f10dda388540a8a8bfab9e76e09cc0e0fca71521. Re-ran all 19 Rust tests and verified main desktop.rs matches the tested source. Both Store agreement flags, argument diagnostics and transient launch-observation recovery are now part of adom/codex. Keeping this issue open only for the remaining live crr install/launch verification: Store agreement acceptance for crr has not yet been authorized. No public runtime or package release was made, and arav-rog was not touched.

Log in to reply.