As of June 8, 2026, the practical question around Codex is no longer only "can it write the app?" For ChatGPT Business workspaces, it can also move closer to shipping one. OpenAI's June 2 Business release notes say ChatGPT Sites is now available in preview for Business workspaces with Codex access, and that Business workspaces have it enabled by default.

That is useful for small teams because many internal tools are not worth a full engineering project: a request tracker, a simple dashboard, a customer handoff form, a lightweight content workflow or a shared checklist. It is also a different risk category from asking AI to draft code in a branch. A hosted internal app has users, access rules, data, maybe file uploads and a URL people may bookmark.

Start with one question: is this app replacing an informal workflow or touching a controlled system? A lunch-order form, a team reading list or a simple status board can be a low-risk first test. A refund approval flow, HR intake form, client file upload area or quote calculator needs more review before anyone treats it as safe.

Use a small rollout checklist before the first Sites deployment.

Name the owner before the prompt

Do not start with the prompt. Start with the owner. One person should be responsible for the app's purpose, source data, access list and retirement date. That owner does not have to be a developer, but they do need enough authority to say "this is only a pilot" or "take this down."

OpenAI's Codex Sites guide describes Sites as a way to create, save, deploy and inspect hosted websites, web apps and games from Codex. It also says every deployment URL is a production deployment. That makes ownership matter. A prototype URL can quickly become the place where people enter real operational data.

Before prompting Codex, write down:

  • Who owns the internal app?
  • Which team or role is allowed to use it?
  • What decision or handoff will it support?
  • What data is allowed inside it?
  • What data is explicitly out of scope?
  • When will the pilot be reviewed or deleted?

If those answers feel too heavy for the idea, the idea may not need a hosted app yet. A shared doc, spreadsheet or project board may be enough.

Save before deploy when review matters

The Sites guide separates saving a version from deploying a version. That distinction is worth keeping even for tiny internal tools. Ask Codex to validate the build and save a deployable version for review before publishing it to the intended audience.

Review the app like a small product, not like a clever demo:

  • Does the first screen make the right action obvious?
  • Does it collect only the data the workflow needs?
  • Does it avoid hidden assumptions about customers, prices, deadlines or permissions?
  • Does it show useful empty states and error states?
  • Does it explain what happened after a user submits or changes something?
  • Does it handle the boring path, not just the happy path?

If a non-technical owner cannot explain what the app stores and who can see it, do not widen access yet.

Keep access narrow at first

OpenAI's Using Codex with your ChatGPT plan help page says Sites can create workspace-internal web apps with Sign in with ChatGPT access, and that admins and owners can manage Sites from workspace settings. The developer guide lists access modes such as owner/admin-only, all workspace users and custom access.

For a first pilot, start with the smallest audience that can test the workflow honestly. Owner plus admins is useful for review. A custom group is better than all workspace users when the app affects one team. Workspace-wide access should come later, after the owner has seen real use and checked the stored data.

Ask for these checks before widening access:

  • Show the current deployment URL and access mode.
  • Confirm the app is still the reviewed saved version.
  • Confirm only the intended users can open it.
  • Confirm who can change or redeploy it.
  • Confirm how the app can be disabled from workspace settings if needed.

This is not bureaucracy. It is a simple guardrail against a generated tool becoming an untracked business process.

Be careful with durable data and uploads

The Sites guide says durable application data and uploaded files need explicit storage choices. That is where small teams should slow down. A stateless calculator or checklist is easier to approve than an app that stores customer records, files, scores, approvals or notes between visits.

Use a simple rule: if people would be upset or exposed if the data were wrong, stale or visible to the wrong person, the app needs a real data review. That review should cover what is stored, how long it should remain useful, who can export or delete it, and what happens when a newer version of the app changes the data shape.

Do not store secrets in app source files. The Sites guide says hosted environment values and secrets belong in the Sites panel, not in project files. Even for an internal tool, treat API keys, webhook URLs, customer tokens and private endpoints as secrets.

Check billing and seat assumptions

ChatGPT Business now has standard ChatGPT seats and usage-based Codex seats, according to OpenAI's Business overview. Standard seats include ChatGPT and Codex access, while Codex seats are Codex-only and usage-based. That matters because an internal app pilot can create two separate costs: the people building with Codex and the ongoing usage pattern if the team keeps iterating.

Before widening a Sites workflow, ask:

  • Which users need Codex access to maintain it?
  • Which users only need to use the hosted app?
  • Is the work consuming workspace credits or agentic usage faster than expected?
  • Is there an owner checking workspace-level spend controls?
  • Will the app still be worth maintaining if usage moves beyond a free preview or initial credit pool?

Do not approve a pilot just because a generated app was quick to create. The maintenance path is the product.

A good first pilot

The strongest first Sites project is narrow, reversible and useful within a week. For example: an internal request dashboard for one operations team, a content brief intake form, a QA checklist for a recurring release, or a lightweight customer handoff tracker that stores only non-sensitive status fields.

Avoid the first pilot if it needs customer payment data, private HR details, regulated records, broad write access to other tools, or promises that must be legally reliable. Codex may still help draft those systems later, but the review bar changes.

The right test is not "did Codex make something impressive?" It is "can the team safely use this without creating an invisible system nobody owns?" If the answer is yes, Sites may be a practical way to turn small internal workflows into real tools. If the answer is unclear, keep the work in review mode and fix ownership, access and data boundaries first.