Codex for Every Role + Codex Sites: The 2026 Team Guide

OpenAI Codex for every role is the clearest sign yet that the company sees Codex less as a coding tool and more as a workforce platform. On June 2, 2026, OpenAI released six role-specific plugins, a prompt-to-app builder called Codex Sites (in preview), and an expanded Annotations feature — all in a single announcement. The question for team leads is no longer whether to notice this, but how to adopt it without creating ungoverned tool sprawl.

We already covered the launch news in our June 2 deep-dive on the Codex business plugin announcement. This piece is different: it is the docs-grounded practical adoption guide. We read the official Codex Sites developer documentation, mapped each plugin to the manual handoff it removes, and weighed Sites honestly against Retool, Lovable, and the rest of the no-code field.

What follows is a role-to-workflow matrix you can hand to department leads, a plain-language explanation of how Sites actually build and deploy, a decision table for Sites versus standalone tools, and the governance questions IT needs answered before the first internal app goes live. Every number here is labeled by source — and where a figure is vendor telemetry or an analyst estimate, we say so.

OpenAI's "Codex for every role, tool, and workflow" announcement, published June 2, 2026, released three things at once. First, six role-specific plugins aimed at analysts, marketers, sales teams, designers, and investors. Second, Codex Sites, a preview feature that lets Codex build and deploy hosted internal apps from a prompt. Third, an expanded Annotations capability that now reaches documents, spreadsheets, and slides — not just code and Markdown.

One practical caveat before the details: as of this guide's publication on June 5, 2026, Codex and ChatGPT remain separate apps. The June 2 announcement framed deeper ChatGPT integration as coming in the following weeks, so treat "inside ChatGPT" as a near-term roadmap item rather than today's reality. For the strategic backdrop on why that integration matters, see the strategic analysis of OpenAI's Codex-ChatGPT merger.

The framing is deliberate. OpenAI is no longer pitching Codex as a tool for engineers who occasionally need help. It is pitching a platform where a marketer, an analyst, or an operations lead can do agentic work that previously required either an engineer or a stack of specialized SaaS subscriptions.

The headline number from the announcement is an adoption curve. OpenAI states that more than 5 million people now use Codex every week — more than 6x growth since the desktop app launched in February 2026 — and that non-developers make up roughly 20% of those users while growing more than 3x faster than developers. These are OpenAI's own usage figures, so read them as vendor telemetry rather than independently audited metrics. The direction, though, was independently echoed in launch coverage.

Here is our read on why that 3x figure should hold the attention of anyone selling software to non-engineering teams. The market for AI-powered work tools appears to be expanding faster outside the engineering function than within it. Engineers already had agentic coding assistants; the next wave of growth is analysts who want to explain a metric movement, marketers who want campaign variations, and sales teams who want a pre-call plan — done without filing a ticket. That is a different, larger market, and it is precisely the one role-specific plugins were built to serve.

The most common way to describe this launch is to count the integrations: 62 popular apps and 110 automated skills across the six plugins. Those are OpenAI's stated totals, and they are not deduplicated — some apps, such as Figma and Canva, appear in more than one plugin — so treat them as headline figures rather than a count of unique integration coverage.

The more useful framing is this: a role plugin encodes an entire professional workflow, not just plumbing. The Sales plugin does not simply connect Salesforce and HubSpot; it knows what a good pre-call plan and a defensible close plan look like. The Data Analytics plugin does not just query Snowflake; it can explain why a key metric changed. That difference — workflow intelligence versus integration wiring — is what separates these plugins from a general-purpose automation connector.

One detail matters for technical leads: each role plugin's source — its instructions, skills, and workflows — is published open on GitHub, so teams can inspect, fork, and customize the bundled behavior rather than treating it as a black box.

Three plugins serve roles where the output is high-stakes and structured: Product Design (Figma, Canva) turns early ideas into reviewable prototypes and can make static screenshots interactive; Public Equity Investing (Moody's, FactSet, S&P, PitchBook and others) supports earnings review and thesis assessment; and Investment Banking helps prepare pitch materials and analyze comparable companies and transactions. OpenAI says five more roles — Corporate Finance, Private Equity Investing, Marketing Strategy, Strategy Consulting, and Legal — are on the roadmap, and that it is building toward an open ecosystem where partners can publish their own plugins.

For deeper role-level context, see the marketing team AI adoption playbook for the Creative Production angle, and the AI finance team playbook for how the equity and banking plugins map onto FP&A work.

Every launch analysis counts apps and skills. Our proprietary read asks a different question that a head of marketing or an operations director can actually use: which of my team's manual handoffs just became optional? The table below maps each live plugin to its target role, its top integrated apps, its core automated tasks, and the dependency it is designed to remove. The five roadmap roles are listed at the bottom, marked accordingly.

Read that "dependency removed" column as a planning prompt, not a layoff memo. The realistic near-term effect is that the person who used to wait on a handoff can now produce a first draft themselves — and the specialist they used to wait on shifts toward review, edge cases, and the work that genuinely needs their judgment.

Codex Sites is the part of this launch most likely to change how non-developers work day to day. Per the official developer docs, Sites lets Codex create, save, deploy, and inspect websites, web apps, and games hosted on OpenAI infrastructure — no separate deployment pipeline required. You invoke it conversationally, for example: @Sites Build a project request dashboard for my operations team. Codex handles the build and hosting.

The mechanics matter for anyone evaluating it seriously. Publishing uses a deliberate two-stage model. First you save a version, which builds the deployable site and ties it to a source Git commit for review. Then you deploy a version, which publishes to production and returns the live URL. That separation is what prevents accidental live deployments — and notably, every Sites deployment URL is a production deployment.

Two technical constraints rarely surface in launch coverage but should shape your expectations. First, Sites hosts projects that build Cloudflare Worker-compatible output as ES modules. That means not every existing internal tool is directly deployable, and the runtime is not traditional Node.js — ask Codex to validate compatibility before assuming you can "migrate the old app to Sites." Second, for persistent data, Sites offers D1 (a relational database for structured data like user progress or scores) and R2 (object storage for files, images, audio, and video), which can be combined for metadata-plus-upload scenarios. Project linkage lives in .openai/hosting.json, and runtime secrets must be set through the Sites panel — never committed in source.

Access control gives you three modes per site: admins_only (owner plus workspace admins), workspace_all (every active workspace user), and custom (specific users or workspace groups). The owner always retains access. On availability: Sites is in preview, free while in preview, and currently limited to ChatGPT Business and Enterprise workspaces, with more plans rolling out later. Business workspaces have Sites enabled by default; Enterprise workspaces require an admin to enable it through role-based access control in ChatGPT admin settings first.

OpenAI positions Sites as complementary to its ecosystem partners, not as a killer app — and the honest comparison reflects that. Sites is fast and tightly integrated for teams already on ChatGPT Business or Enterprise, but it trades away code portability, external-user flexibility, and federated identity. The matrix below is our proprietary read, combining the Sites developer docs with the published positioning of the main alternatives. It is built to help a team lead pick per-use-case rather than per-headline.

The displacement question worth naming honestly: when Sites and the Data Analytics plugin work together, internal-tool builders and BI dashboarding layers face the most direct pressure for ad-hoc work. One analyst framing put it bluntly — the immediate winner is a company already on ChatGPT Business or Enterprise, which now has an internal-tool builder inside its existing subscription. That said, organizations that require infrastructure portability or external customer access should still evaluate the alternatives above; the Cloudflare runtime constraint and the SAML gap are real, not cosmetic. If you are weighing this trade-off across your stack, our 2026 build-vs-buy decision framework for AI tools walks through exactly this kind of call.

Here is the honest part of any adoption guide. Sites being free in preview is an opportunity and a risk at the same time. The low barrier means anyone in a Business workspace can spin up an app in minutes. But at launch, OpenAI published no usage caps, no admin dashboard for monitoring which Sites apps get built, and no approval workflow for deploying them. The two-stage save-then-deploy model helps, but it does not substitute for organizational policy. Enterprise IT departments will need to define their own guardrails.

Workspace admins do have some controls. Business and Enterprise admins can manage the underlying app permissions for role plugins in workspace settings, and Enterprise admins must explicitly enable Sites via RBAC before members can use it. Use that toggle as your first governance lever: decide deliberately when to turn Sites on, rather than discovering a sprawl of internal apps after the fact.

Two more rollout notes. OpenAI made its frontier models and Codex available on AWS on June 1, 2026, the day before this plugin launch — relevant if your enterprise deployment decisions are tied to a particular cloud, though confirm the exact scope on OpenAI's own page before planning around it. And the agent powering Codex runs on GPT-5.3-Codex, OpenAI's coding-focused model; note that higher-tier model names are sometimes assumed but the Codex agent is specifically GPT-5.3-Codex.

Step back from the feature list and the strategic shape is clear. OpenAI is positioning Codex as an orchestration layer. The plugins sit above your SaaS tools, encoding the workflows that used to live in people's heads or in scattered SOPs. Sites sits alongside deployment platforms — Vercel, Wix, Replit, Figma, Webflow, and the other named early partners — as a hub for spinning up lightweight internal apps, not as a replacement for production infrastructure. The "hub, not replacement" logic is the part most launch coverage missed.

Projecting forward, the practical effect on team structure is a shift from handoffs to review. When an analyst can build a first-pass dashboard and a marketer can generate ad variations without filing a request, the engineers and designers they used to depend on move up the value chain toward judgment, edge cases, and the work that genuinely needs a specialist. The risk to manage is the inverse: a proliferation of half-governed internal apps that nobody owns. The teams that win with this will be the ones that pair the low barrier with a deliberate policy, not the ones that simply turn it on.

For agencies specifically, this reshapes what clients can do themselves versus what they still need help with. The commercial framing — what to charge for in a world where clients have agentic tools — is worth working through; our AI agency pricing model guide covers that, and for the broader product context see the Codex Desktop and Computer Use guide. Where teams want help standing this up safely — choosing which workflows to move onto plugins, scoping a Sites pilot, and writing the governance OpenAI left to customers — that is exactly the kind of work our AI transformation engagements are built for.