> ## Documentation Index > Fetch the complete documentation index at: https://docs.useorgx.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # Cloud agents > Prepare OrgX in a reusable cloud image, activate with runtime credentials, and verify native session delivery. 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](https://github.com/hopeatina/orgx-wizard/blob/main/cloud/SKILL.md), or generate the configuration directly: ```bash theme={"dark"} npx --yes --package=@useorgx/wizard@0.1.92 orgx cloud recipe \ --provider codex-cloud --auth-mode proxy-placeholder --json ``` 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](https://docs.useorgx.com/docs/resources/security.md). ## Place each step in the right phase | Host | Install | Runtime | | - | - | - | | Current Codex Cloud | Put the generated install script in the environment's Install script; publish the prepared filesystem. | Use the Start skill to run the generated startup check. Verify native hooks and trust in a new task. A Start skill is an agent instruction, not an enforced pre-action boundary. | | Claude Code cloud | Use the environment setup script before Claude launches. Session variables and proxy network secrets are unavailable in this phase. | Native SessionStart hooks run after launch, including resumed sessions. Run the startup check when runtime credentials are available. Do not install activation recursively as its own SessionStart handler. | | Other configurable containers | Use `--provider custom --client claude-code`, `codex`, `cursor`, or `gemini` only when that native client actually executes the task. | Run startup from the container entrypoint or the host's supported task startup mechanism. Verify the real native event payload. | 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: | Transport | Runtime requirement | | - | - | | `direct` | The process reads `ORGX_API_KEY` supplied by the host. No credential is written by cloud preparation. | | `proxy-placeholder` | The host supplies an `ORGX_API_KEY` placeholder and substitutes it only for the allowed API origin. OrgX sends the placeholder unchanged. | | `proxy-header` | The host attaches `Authorization: Bearer …` after the request leaves the environment. OrgX sends no local Authorization header and does not require a locally readable key. | Both proxy modes skip stored credential fallback. Set the non-secret `ORGX_AUTH_SCOPE=:`; activation checks it against `/me` before reporting readiness. Prefer a credential bound to the intended workspace. Use `--workspace ` 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. ```bash theme={"dark"} orgx cloud activate --json orgx cloud doctor --session-id --require-delivery --json ``` 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 ```bash theme={"dark"} orgx cloud providers --json orgx cloud uninstall --json ``` 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](https://learn.chatgpt.com/docs/environments/cloud-environments), [Claude cloud](https://code.claude.com/docs/en/cloud-environments), and the [official partner directory](https://learn.chatgpt.com/docs/sign-in-with-chatgpt). This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.