future: provision Codex Computer Use prerequisites during Host setup

[Microck]

satelle setup currently assumes that the supported Codex runtime and Computer Use plugin already exist on the Host.

the MVP already owns Satelle distribution, Host setup, and verification of the exact supported Codex runtime receipt. this issue tracks post-MVP automation for provisioning the upstream Computer Use prerequisites themselves.

scope

• acquire and install an exact supported first-party Codex runtime
• verify its package, binary, target, version, digest, and Codex home before use
• detect whether the Computer Use plugin is installed and enabled
• use action_required when plugin installation must happen through the ChatGPT desktop UI
• detect missing OS permissions and native app approvals
• give exact remediation steps and recheck after the operator completes them
• preserve Host-side authentication and secret boundaries
• use the normal setup plan, dry-run, consent, action ledger, repair, and postcheck contracts
• never auto-answer OS, administrator, security, app, or sensitive-action prompts

out of scope

• silently granting OS permissions
• bypassing native security prompts
• treating plugin presence as proof that Computer Use works
• guaranteeing that prompt turns use Computer Use

the last point is a separate current execution-contract blocker, not future installation work.

[Microck]

did some implementation research so this does not have to be rediscovered after the MVP.

short version

Codex itself can be installed and authenticated from the operator machine over Satelle's existing SSH setup transport. Computer Use cannot honestly be zero-touch on a fresh unmanaged desktop today because the ChatGPT desktop plugin and OS privacy permissions still need local UI approval.

I think the right contract is:

• --component codex: fully operable from the operator machine, assuming the existing SSH or management foothold works.
• --component computer-use: fully operable from the operator machine only when the desktop host was already enrolled. Otherwise setup returns a typed action_required response with exact local steps, then the operator resumes and verifies it remotely.

recommended implementation shape

Keep one setup workflow and one remote transport. Do not add a second provisioning channel.

The ordered actions should be:

1. codex.acquire
2. codex.install
3. codex.verify
4. codex.write_receipt
5. codex.authenticate
6. computer_use.check_plugin
7. computer_use.check_os_permissions
8. computer_use.live_probe

Each action should participate in the existing setup plan, dry-run, consent, ledger, repair, and post-check flow.

fix the launch contract first

The current Host runtime probes and launches Command::new("codex"). That makes provisioning depend on the target user's mutable PATH, which is not a trustworthy install contract.

The repo already has a resolved contract for OpenAI standalone Codex 0.144.0. Setup should:

• select the exact release asset for the target OS and architecture
• verify it against the release SHA-256 manifest
• install it under Satelle-owned package storage
• write a receipt containing the immutable executable path and digest
• make Host launch Codex through that receipt

Host should ignore npm installs, shell shims, and whichever codex happens to appear first on PATH.

OpenAI's standalone installers support non-interactive installation and explicit release/home/install locations. The pinned release is here: https://github.com/openai/codex/releases/tag/rust-v0.144.0

authentication

Do not copy auth.json from the operator machine and do not scrape terminal output.

Codex app-server has a structured device-code login flow. Satelle can start account/login/start with chatgptDeviceCode, return the verification URL and user code to the operator, wait for account/login/completed, and then run a real authenticated probe.

The device code is transient input. Do not persist it in the setup ledger. If login expires, return a new required action instead of trying to reuse it.

Official headless login docs: https://learn.chatgpt.com/docs/auth#login-on-headless-devices

Computer Use boundary

The pinned app-server schema exposes plugin methods, but its README marks plugin/list, plugin/installed, and plugin/install as under development and says production clients should not call them yet: https://github.com/openai/codex/blob/rust-v0.144.0/codex-rs/app-server/README.md

So the first implementation should not automate private plugin state. It should:

• detect whether the ChatGPT desktop app and Computer Use plugin are ready
• detect whether required OS permissions are present
• return typed required actions when local approval is needed
• resume the same setup operation after the user completes them
• finish with a live Computer Use probe from a fresh Host process

Useful required-action kinds:

• codex_device_auth
• computer_use_plugin
• macos_screen_recording
• macos_accessibility
• windows_active_desktop
• app_approval

Each action should have a stable ID and a state such as pending, completed, expired, or blocked. This probably deserves a schema bump instead of overloading the current setup input prompt type.

Computer Use also requires a visible, unlocked desktop on Windows, and macOS requires Screen Recording and Accessibility approval. Satelle must not auto-answer security, privacy, or sensitive-action prompts. Official constraints: https://learn.chatgpt.com/docs/computer-use

acceptance criteria

For Codex:

• start with a host that has no Codex binary
• run setup only from the operator machine
• verify the exact artifact digest and receipt
• complete device-code login from the operator side
• restart Host with a clean PATH
• prove an authenticated Codex request works through the receipt-selected executable

For Computer Use:

• prove the positive operator-only flow on a pre-enrolled desktop host
• prove a fresh host returns the exact local actions still required
• resume after those actions without reinstalling or losing prior authorized state
• run a live probe from a fresh process
• prove setup never bypasses OS or app approval prompts

The main thing I would avoid is calling the issue done after implementing only refusal or detection. The Codex positive path should be real and end-to-end. The Computer Use positive path should also be real on a pre-enrolled machine, with action_required reserved for the upstream UI and OS boundaries Satelle cannot remove.