跪拜 Guibai
← All articles
Frontend · Backend · JavaScript

Codex Isn't a Chatbot — It's a Seven-Layer Configurable Workbench

By ikoala ·
Read original on juejin.cn ↗ Google Translate ↗ Alt translation

Most developers treat Codex as a smarter terminal prompt and then wonder why it ignores project conventions or can't access real data. Understanding the seven-layer configuration model — and the read-vs-write safety boundary — turns it from a chat toy into a persistent, tool-using workstation that actually respects how a team works.

Summary

Codex ships with a CLI, a desktop app, and IDE extensions, but its real structure is a seven-layer configuration system. Temporary instructions belong in the conversation, project-wide rules live in AGENTS.md, runtime defaults sit in config.toml, repeatable workflows become Skills, capability packs are Plugins, external tools connect through MCP servers, and long-term preferences go into Memory. Each layer answers a different question: how this project works, how Codex itself runs, how to standardize a recurring task, and how to reach real data.

A beginner's path starts with installing the CLI and desktop app, running codex doctor to verify the environment, writing a minimal AGENTS.md with project commands and constraints, and setting conservative sandbox and approval defaults. Only after that baseline works should someone add one plugin, then one MCP server, then a Skill for a task they repeat weekly. The most common mistakes are granting danger-full-access too early, treating AGENTS.md as marketing prose instead of an operational checklist, and confusing Memory with a fact database.

Plugins, MCP, and App Connectors all bridge Codex to real tools — GitHub, Gmail, Figma, browsers — but they differ in protocol and authorization model. The safety rule is simple: reads can be automatic, writes must require confirmation. A well-configured Codex stops being a prompt box and becomes a persistent AI workstation that accumulates project knowledge over time.

Takeaways
Codex is not a single chat window; it is a configurable workbench with seven distinct layers: conversation, AGENTS.md, config.toml, Skills, Plugins, MCP, and Memory.
AGENTS.md is the project manual for the AI — it should contain startup commands, coding constraints, directory structure, and verification steps, not prose.
config.toml controls Codex's own runtime behavior: model selection, sandbox permissions, approval policy, and MCP server definitions.
Skills are repeatable operating procedures for a specific task type, distinct from AGENTS.md which governs the whole project.
Plugins are capability packs that can bundle Skills, MCP servers, App connectors, and scripts together.
MCP (Model Context Protocol) is the standard way to connect Codex to external tools and data sources like GitHub, databases, or internal APIs.
Memory stores long-term preferences and habits, not facts or secrets — project state and live data should come from real sources.
Beginners should start with conservative sandbox and approval settings, not danger-full-access, and add capabilities one layer at a time.
Read operations can be automated; write operations that produce external side effects should always require human confirmation.
The recommended first-week setup is: one AGENTS.md per project, codex doctor for diagnostics, and exactly one plugin or App connector.
Conclusions

The seven-layer model reframes Codex from a prompt-response tool into a persistent system that accumulates institutional knowledge — project rules, workflows, and tool connections survive beyond a single session.

Most beginner frustration with AI coding tools comes from misplacing configuration: stuffing project rules into prompts, treating memory as a database, or granting full filesystem access before understanding the sandbox model.

The distinction between MCP, Plugins, and App Connectors is subtle but consequential — they solve the same problem (connecting to real tools) through different authorization and packaging models, and Codex will prefer whichever is most stable in the current environment.

Codex's design encourages a gradual onboarding path where each configuration layer is validated independently, which is the opposite of how most developers approach new tools — they install everything at once and then can't isolate failures.

Concepts & terms
AGENTS.md
A project-level Markdown file that tells Codex how the project works: startup commands, coding rules, directory structure, and verification steps. It functions as an operational manual for the AI, not a human-facing README.
config.toml
Codex's global runtime configuration file (typically at ~/.codex/config.toml) that controls model selection, sandbox permissions, approval policies, and MCP server definitions. Can be temporarily overridden with the -c flag.
Skills
Reusable Markdown files (stored in ~/.codex/skills) that define a standard operating procedure for a specific task type, such as writing articles or reviewing PRs. They include a trigger description, step-by-step workflow, and verification criteria.
MCP (Model Context Protocol)
An open protocol that lets Codex connect to external tools and data sources — GitHub, databases, browsers, internal APIs — through a standardized interface. MCP servers can run locally (stdio) or remotely (HTTP).
Plugins
Capability packs in Codex that bundle Skills, MCP server configs, App connectors, scripts, and metadata together. Installed via codex plugin add and managed through the CLI or desktop app marketplace.
Memory
Codex's long-term preference store for habits and style choices (e.g., 'answer in Chinese,' 'prefer practical writing style'). It is not a fact database and should not store secrets, live data, or project state.
codex doctor
A CLI diagnostic command that checks Codex's installation, configuration, authentication, and runtime health. It is the first troubleshooting step when tools, MCP connections, or permissions don't work as expected.
Source: juejin.cn ↗ Google Translate ↗ Backup ↗