Start with a place for your agent to work. It checks what’s missing and handles the technical setup. You sign in to your own accounts and approve changes that need your say.
On your computer, open Codex and choose a project folder. An empty folder is fine. If you already have a project open, stay there.
The automated reference setup is currently verified on an Apple Silicon Mac. Other systems need separate agent-led verification. You don’t need to buy an API key to copy this handoff.
Keep Set up my first app selected, copy the handoff, paste it into the Codex chat for that folder and send it. You can say “I don’t have a domain” or “I already use Cloudflare.” No project brief is needed.
The agent checks what you already have, then prepares the supported starter. You handle sign-in and approve changes that need your say.
Prepare my environment before asking for an app idea. Use App Composer’s current Get Ready implementation at https://github.com/loftwah/app-composer. Read its trusted AGENTS.md and supported setup instructions in README.md; use the one lib/get-ready engine, not a new checklist or planner. Work in this authorised Codex folder. If a Get Ready MCP is already connected for this exact host-selected workspace and target, its check/inspect tools can perform read-only verification; they cannot execute setup. Otherwise use the same engine through the doctor command. Before changing an actual output project, use the same core’s inspectProject API or --inspect-project mode (or its host-selected get_ready_project tool). Inspect that project’s declarations, existing guidance and canonical skills without replacing them. Check user/plugin copies before installing duplicates. A file or matching entrypoint does not prove installed version, agent visibility, exercised capability or readiness; recheck the output project’s actual environment separately. Keep credentials out of chat and specifications, preserve existing files and save resumable evidence privately. Report what you actually checked, the next step and any precise human action. Give me a redacted progress JSON export using the doctor’s --report flag; never share its private receipt. Check the available tools, GitHub access and my selected Cloudflare account. If I select an existing custom domain, use the same core’s read-only diagnoseDomain API or --inspect-domain mode for the exact intended zone/account. Return its separate portable domain report, inspect nameserver/DNSSEC findings and preserve current website/email records. A resolver observation is not permission to change nameservers or proof of HTTPS. On the supported Apple Silicon Mac with Node 22 and Git, use the explicit install-workspace-tools step if GitHub CLI or pnpm is missing. Reuse verified prepared tools across the new checkout with tools-workspace; inspect partial folders before retry. Other repairs use official instructions. Continue independent checks when one step is blocked. Use supported operations to acquire the maintained Hello starter, prepare my private source and tools, then deploy to an unused workers.dev address in my existing authorised account. Confirm the intended owner and destination; never use the launch operator’s account or domain for me. Recheck the exact source over HTTPS. First accounts, new domains and unsupported runtimes still need separate setup: explain the gap honestly. Ask MP for unavoidable sign-in, purchases, expanded permissions or consequential approvals. Do not stop at a plan.
Want to look first? Choose Check what is ready for a read-only check. After finishing a login, choose Continue after sign-in to recheck saved progress before another setup attempt.
The handoff asks the agent to inspect your actual environment. This website cannot install tools or change your accounts by itself.
Your agent can prepare the reviewed tools inside your selected project folder on an Apple Silicon Mac with Node 22 and Git. It first checks what already works, verifies the downloads and preserves existing files. The same tools can be reused when it moves into your starter checkout.
You don’t need to edit your shell settings or choose a package manager. Other systems, missing Git or Node, and account sign-in need separate checks. Read the supported preparation step.
Check missing tools, GitHub access and the correct Cloudflare account and destination. If you need the starter code, the supported clone operation can start from your empty Codex folder and prepare a new checkout without overwriting your files. The agent checks that checkout separately and can install its pinned local tools.
For your own source, the agent can explicitly create a new private repository in your personal GitHub account. It checks the owner, name and pushed code, then points your checkout at that repository. Existing names are preserved. The agent can prepare local tools for this unchanged private starter too. Once its local tools work, the agent can prepare a deployment configuration for an unused workers.dev address in your existing Cloudflare account. This changes only a local file. The agent can review and commit that file, deploy the unchanged owned starter to the new address and verify its exact source over HTTPS. After verification, use Init to change its title, introduction and theme. The agent reviews the saved specification and checks the changed live page.
The agent should name the exact human step when one is needed, save progress privately and continue other checks. It must check again after a fix. Copying code or installing tools never grants permission to deploy.
Keep passwords, verification codes and secret keys in the official sign-in screen or your password manager. Never paste them into this website, a specification or a chat message.
Being signed in to GitHub in a browser does not sign in the tools in your agent’s folder. Your agent checks that connection first and starts the official login only when it is needed.
If you need an account, use GitHub’s own signup. You handle its terms and account verification. If sign-in works but the repository refuses writes, the agent checks the account, repository and required access; signing in repeatedly will not add permission.
Use the verified GitHub CLI selected for this workspace, including a prepared workspace pair when needed. Check gh auth status --active --hostname github.com. Its JSON output can exit successfully even when authentication is invalid, so do not treat that exit code alone as proof.
When a new browser login is actually needed, use gh auth login --hostname github.com --git-protocol https --web --skip-ssh-key in an interactive terminal. Review existing token-based authentication before switching methods. Do not request extra scopes or change Git’s global credential helper just to pass the doctor. Check that the runtime has a secure credential store before login: GitHub CLI can otherwise fall back to a plaintext file. Do not select insecure storage for this journey.
Keep tokens, device codes and account-specific command output out of progress reports. A successful login is separate from repository write access and deployment authority.
Official GitHub CLI login instructions · Authentication status reference
You decide whether to accept a new subscription, billing commitment or permission. The agent should explain the cost before asking. An alert is not a hard spending cap.
A domain is your web address, such as example.com. Tell the agent its name. Its read-only domain diagnosis checks the exact account’s zone, compares assigned and observed nameservers and inspects DNSSEC/DS records. Open that report in Get Ready’s domain viewer. It still reviews current website/email records and the intended app address before proposing a change. You normally do not need to change nameservers again.
Do not delete existing mail or website records to make a setup check pass. The agent must preserve them or explain a necessary change.
Only do this when the agent has reviewed the current DNS records and you have agreed to move DNS to Cloudflare. Nameservers tell the internet which service holds your domain’s address book.
Namecheap’s current instructions and screenshots · Cloudflare’s nameserver instructions
If Cloudflare is your registrar, or DNS is already active there, skip this change. Other registrars use different screens; let the agent find their official instructions.
Tell your agent. A domain purchase needs your approval; it should never buy one because a form suggests it. For the supported private starter, your agent can prepare and deploy an unused workers.dev address in an existing authorised Cloudflare account. The maintained launch reference uses its existing Worker and route. New account setup and changes to the app’s source code still need completion.
The agent should give you an HTTPS link to your reference app and evidence that it deployed the intended source. Open the link. The agent should also change the greeting and deploy again. Refresh and check the new greeting.
Your agent can give you a redacted JSON progress report. On Get Ready, use Open your agent’s report and choose that file. The page reads it on your device and shows which checks need attention.
Use the export, not the agent’s private receipt. A dated report cannot check your computer by itself or grant permission to deploy; ask your agent to recheck after changes.
That proves more than a checklist: the agent can build, deploy and change the app you own. Only then move to Init to describe the app you want.
The form saves only a local draft. Temporary-address intent can configure your already verified private starter; it creates no new deployment destination. A new-domain choice remains exploration. Supported Hello configuration details.
Tell the agent what the screen says, leaving out secrets. It should identify one specific action, such as finishing GitHub login, then resume from the saved progress. Provider outages and routine repairs belong to the agent.
Working today: one reusable readiness engine, private resume, new personal private source repositories and supported maintained-reference installation/configuration/deployment on the verified Mac path. The unchanged private starter also supports initial workers.dev deployment. New account/domain bootstrap, general source updates/cleanup and hosted API/MCP still need completion. Read the current evidence.
Get Ready is the first part of a longer journey. Each stage should leave you with something you can use and keep.
A working environment, before you need an idea. The supported path checks Codex, GitHub and Cloudflare, prepares your private starter and verifies HTTPS.
First accounts, more agents, operating systems and registrars still need implementation and verification.
Choose an app and its settings. Take the portable specification to your agent, then inspect the changed live result.
Hello supports title, introduction and theme; the photo pair also has layout and collection settings. Design fields and forms with groups, conditions, repeaters and native EmDash seed export. Your agent implements and verifies the customer app.
Your agent owns the code, checks and release. You handle sign-in, spending and consequential approvals when they are needed.
The photo guestbook provides approved items to the showcase. Feature one, open its original, then hide it at the source to revoke both public views.
Keep the GitHub source, configuration and history. Controlled Hello updates and the photo pair’s pinned releases work today.
General source updates, cleanup and complete recovery remain open.
See how the parts connect · Try the building blocks · Read the verified outcomes
Vendor instructions reviewed 14 October 2026. Official guides include the current provider screenshots; this page does not imitate account or sign-in screens.