Skip to main content
OrgX cloud setup separates image preparation from runtime verification. Install once in the reusable image; each task uses its own credentials and native session identity. Resume checks use the installed binaries without downloading another package.

Generate the installation

Give your setup agent the cloud installation skill, or generate the configuration directly:
For Claude Code cloud, use --provider claude-cloud. Its recipe defaults to proxy-header, for hosts that attach an Authorization header to outgoing requests. Use --auth-mode direct only when a credential is available to the actual runtime process through supported secret controls. The JSON contains installScript, startupScript, secret/environment fields, network destinations, capture scope and verification steps. Both orgx cloud and orgx-wizard cloud use the same implementation. Recipes require a POSIX environment and Node 22.21 or newer for environment-proxy support. If you already signed in through the local Wizard, add --resolve-identity to fill the workspace and actor fields from /me. The lookup uses the existing credential only for its own origin, never starts login, and prints no key. Without the flag, recipe generation stays offline. The OrgX shim sends native hook payloads, including prompts, tool arguments, working directory and session identifiers, to OrgX. Trail receipt uploads are off by default. Add --receipts content only to authorize redacted prompts, summaries, commands, output excerpts and human corrections as receipts. Personal-data masking is a separate Trail setting; redaction does not guarantee confidentiality. Review data handling.

Place each step in the right phase

Preparation registers static hooks without opening a browser, authenticating, creating a workspace or creating a session. It preserves unrelated hooks and can be repeated on a clean image. It refuses an image containing task delivery state. Preserve that data for delivery or recovery; prepare a fresh image. Never put credentials, login caches, session IDs, transcript history, pending receipts or running worker state in a published image. A background process started during image preparation is not a reliable runtime worker.

Supply runtime credentials

Configure the recipe’s fields through the host’s secret controls: Both proxy modes skip stored credential fallback. Set the non-secret ORGX_AUTH_SCOPE=<workspace-id>:<actor-id>; activation checks it against /me before reporting readiness. Prefer a credential bound to the intended workspace. Use --workspace <uuid> in the recipe to require that default/bound workspace. Keep raw keys out of chat, repositories, command-line arguments and shell startup files. Preserve inherited proxies and CA trust. Enable API access to useorgx.com during tasks; package installs need registry access during image preparation. Hosted MCP additionally needs mcp.useorgx.com when selected. The recipe identifies destinations but does not grant network access. Legacy Codex Cloud has a different setup/maintenance lifecycle and setup-only secrets. --provider codex-legacy does not turn a setup-only secret into runtime authentication. Use a supported runtime transport before claiming activation.

Verify a real session

Run the startup script after runtime credentials are available, then start a new native session. Codex may skip hooks until they are trusted through its native /hooks flow or a supported host-managed mechanism. OrgX does not write trust hashes or bypass that control.
The versioned JSON separates prepared files, configured hooks, trust, authentication, synthetic checks, real event transport and receipt acknowledgements. Synthetic SessionStart/pre-tool checks write no task delivery evidence. A real hook HTTP acknowledgement is local transport evidence; it does not establish ledger persistence. When content receipts are selected, --require-delivery also requires a receipt API acknowledgement. Human acceptance is a separate fact. Trail starts its incremental worker from supported runtime events. Missing transcript_path/transcriptPath means no automatic receipt can be produced. Rejected uploads remain retryable through persisted checkpoints; an abruptly destroyed ephemeral filesystem can still lose unacknowledged data.

Compatibility and removal

The registry includes all 16 DevDay Sign in with ChatGPT plan-usage/open-source partners. Membership does not establish configurable environments or native event access. Amp setup/resume and Devin blueprints have documented environment extension points; their native OrgX event adapters remain unverified. Existing OpenCode/OpenClaw plugins are separate integrations. An MCP connection observes OrgX tool calls, not the host’s other tool activity. Local end-to-end fixtures verify the CLI, hook processes, Trail worker, retries, receipt acknowledgements and uninstall. Hosted loader/proxy behavior still requires a real task in each provider; the registry does not certify it. Uninstall removes this configuration and preserves queued receipt data and unrelated hooks. Update by rebuilding a fresh image from the new pinned recipe, then verify a new task and a resume. Provider references: Codex Cloud, Claude cloud, and the official partner directory.