A Minimal Codex Setup for Web Development

① Core: get these foundations right

The core setup is not a row of plugin cards. It is the foundation that lets development work run and be verified. You can start with zero plugins. That does not mean the project needs no configuration, and it does not mean Codex or third-party services are necessarily free.

Codex: the primary development agent

Use Codex as your development agent: it reads and edits project code, runs commands within the permissions you grant, and checks the outcome. You do not need to connect every external tool before starting a web project.

Project environment: make the project work first

Confirm that the project has the runtime it actually needs, the correct package manager, installed dependencies, required environment variables and working startup scripts. Not every project uses Node.js, and not every project uses pnpm.

Codex can only work effectively when the project itself can run. If the local environment is broken, installing more MCP servers does not repair the underlying problem.

OpenAI's account of using Codex emphasizes incrementally improving setup scripts, environment variables and the development environment. Current best practices also start with basics such as the working directory, permissions and missing tools.

Give Codex a map, not an encyclopedia

AGENTS.md can explain how to run the project, which commands verify it, where important directories live, which naming conventions apply, what should not be changed, and any special constraints.

Do not paste dozens of pages into it. A very large instruction file consumes context and is more likely to accumulate outdated rules. That is an engineering lesson from OpenAI's Harness Engineering, not a universal line-count limit.

A useful division is: AGENTS.md is the map; README, docs/, ARCHITECTURE.md and DESIGN.md hold the detail. Keep only what matters to the current project.

A minimal AGENTS.md example

This is a structural example, not a template every project must copy. Replace the commands and document paths with files that really exist in your repository. Do not claim tests exist just to match the example.

# AGENTS.md

## Project

Next.js application using TypeScript.

## Commands

Install:
pnpm install

Development:
pnpm dev

Lint:
pnpm lint

Test:
pnpm test

Build:
pnpm build

## Rules

- Use TypeScript strict mode.
- Reuse existing components before creating new ones.
- Do not change production secrets.
- Run lint, test and build after meaningful changes.

## Docs

- Architecture: docs/architecture.md
- Design system: docs/design-system.md

Keep it concise, accurate and maintained. Avoid outdated rules, dozens of fictional roles, a long project history or information unrelated to current work. AGENTS.md is not mandatory, but it is usually worth maintaining for an ongoing project.

Verification matters more than another plugin

A production web project should usually expose lint, test and build checks; add typecheck or E2E when the project needs them. Each catches different problems. None guarantees that every bug will be found.

If these scripts exist in your project, Codex can run them after a change:

pnpm lint
pnpm test
pnpm build

Use the scripts your project actually defines. These are not universal commands for every stack. When a check fails, fix the code, test or environment rather than hiding the failure behind more integrations.

② Recommended: add Playwright CLI when a browser matters

For a site, web app, login flow, form, responsive layout, page interaction, UI regression or screenshot check, Playwright CLI can be valuable. It is a recommendation for browser work, not a requirement for every project.

Playwright's Coding Agents documentation presents the CLI for coding-agent workflows. Command-based interaction fits an agent that already has shell access. It can return accessibility snapshots, take screenshots, maintain browser sessions and optionally load Skills.

Its context overhead is lower relative to MCP, but it is not cost-free and it will not be lighter for every possible task. Read Playwright MCP vs CLI and Is Playwright MCP worth installing? for the full distinction.

Install only when you need it

The reviewed official command is:

npm install -g @playwright/cli@latest

Check the help output:

playwright-cli --help

Optionally install Skills:

playwright-cli install --skills

Skills are optional. A coding agent can use the CLI without them and consult playwright-cli --help. This site displays the commands but never installs or runs them. Read the official installation requirements before first use.

What about Playwright MCP?

③ Optional: add a tool after the problem appears

The options below describe specific capability gaps, not a ranking. Identify what is missing before choosing how to connect it.

Context7: when current library documentation is a recurring need

Consider Context7 when you repeatedly work with fast-moving frameworks, the agent's built-in knowledge is stale, or you regularly need current API and library documentation.

It may be unnecessary when the stack is stable, official documentation already lives in the project, current context is enough, or the need is occasional.

Context7 can be used through MCP and also has a Codex plugin form. Its own plugin documentation describes a combination of MCP and Skill capabilities. This page does not tell you to install it, and it does not link to an unpublished tool page.

Figma: when the source of truth really is in Figma

Consider a Figma connection when implementation must closely match a Figma file, the design system lives there, or the project relies on a design-to-code workflow. It is probably unnecessary for a backend-only project, a fully code-owned UI or a handful of simple screens.

The OpenAI plugins repository includes Figma-related examples, but availability can depend on the account, workspace, region and current product interface. Do not assume every Codex user has the same Figma plugin.

GitHub: when local Git is not enough

Within an approved project environment, Codex can use git and other available CLI tools. Viewing a diff, committing, switching branches or reading local history does not necessarily require another GitHub integration.

When a task needs Issues, pull requests, remote-repository data or account actions, compare a GitHub plugin, app, MCP server or gh CLI. Check whether git and gh already solve the problem before adding another layer. Do not assume gh is installed or authenticated.

Notion / Linear: only for the team's real workflow

Connect one of these services when the team genuinely keeps requirements, tasks, project management or documentation there. If the project does not use the service, do not introduce it just to make the workflow look more “AI-powered.”

Sentry: for deployed projects that already use it

Consider a Sentry connection when the project is already integrated with Sentry and Codex needs real error data to investigate a production incident. A local learning project that has not deployed or does not use Sentry does not need it for this setup.

④ Skip these when there is no clear need

This section is about duplicated or unnecessary capabilities, not a ranking or attack on a product. The same tool may be useful in a different project.

How should you think about plugins, Skills and MCP?

They are not mutually exclusive. A plugin can package Skills and connected apps, MCP connections or other capabilities. Whether it includes app templates or another resource depends on that plugin; none is guaranteed for every package.

To separate working methods from tool connections, read Skill vs MCP.

The current Codex plugin ecosystem: installable does not mean necessary

OpenAI provides a Plugin Directory. The current official explanation describes plugins as packages for reusable workflows, while the public examples repository shows combinations of Skills, app connections and MCP.

Some plugins work without an external app; others need an external account connection before tools are available. Check the current product UI and the plugin's own description. Workspace, plan, region and entry point may affect availability. Not every plugin is available to every user.

This is context for understanding the ecosystem, not an instruction to open the directory and install everything.

The actual minimal Codex setup for web development

The foundation is a project that can be developed and verified. AGENTS.md is useful in the starting setup, but it remains a recommendation. Codex can work without one.

Three setup variants

Does your project need another tool?

A web feature from start to finish

Suppose the request is: “Add a forgot-password flow to the login page.” This is a workflow example, not a record of a real test completed by this site.

Read AGENTS.md, if present
↓
Inspect the project structure
↓
Modify the code
↓
Run lint / test
↓
Run build
↓
If UI verification is needed, use Playwright CLI
↓
Capture / inspect the result
↓
Fix problems and verify again

This flow does not require ten MCP servers. Browser verification should also use an authorized test environment and test data, not send real reset emails or change a production account without permission.

Fewer tools make failures easier to diagnose

Imagine adding five MCP servers, eight Skills and six plugins. Those numbers illustrate configuration complexity; they are not benchmark data. When something fails, it becomes harder to tell whether the cause is Codex, the project, a Skill, an MCP server, a plugin, permissions or a third-party service.

More tools can also consume additional tokens and context. The real impact depends on how the tool loads and what the task requires; there is no universal percentage.

Our recommendation is simple: add one thing at a time. Use it on real work. Keep it if it helps; remove it if it does not. When you need to configure or remove an MCP server, read How to add an MCP server to Codex.

A small community signal

Frequently asked questions

Does Codex require MCP for web development?

No. Start with the project environment, instructions and verification tools. Add an external connection only when a specific capability is missing.

Does Codex require a plugin?

No. You can start development with zero plugins. Plugins are optional capability packages.

Is AGENTS.md mandatory?

No. For an ongoing project, a concise and accurate AGENTS.md is usually worth maintaining because it helps Codex find project rules and documentation.

Should I install Playwright MCP or CLI?

For a typical coding-agent web workflow, try the CLI first. Consider MCP for exploratory agents, structured browser tools and persistent sessions. See the full comparison rather than deciding from popularity.

Is Context7 a must-have?

No. Consider it only when current third-party library documentation is a recurring need and your existing options are not enough.

Is a Figma plugin required?

No. It makes sense when the workflow genuinely revolves around Figma and the relevant capability is available to your account and entry point.

Does installing more MCP servers make Codex stronger?

Not automatically. More tools also add configuration, permissions, maintenance, context and troubleshooting work. Keep the ones that clearly help.

Less, but better. Start with the minimum and add only what the work demands.