Skip to main content
What this unit solvesYou are not learning four tools; you are learning the same set of concepts under four different names. Using 02-2 Claude as the baseline, map OpenAI Codex, Google Antigravity, and GitHub Copilot onto the 02-1 layer model: where personalization is configured, what privacy opt-out is called, which file holds project rules, whether an automation mechanism exists, how memory is stored, and where MCP connects. Cursor, as a third-party IDE, appears only in a brief section at the end. Once the mapping is done, switching tools means consulting a table, not relearning from scratch.How this page differs from 04-0 .claude directory reference: 04-0 is the complete reference for Claude’s own .claude/ directory. This page uses Claude as the baseline and shows configuration directory comparisons across tools.

Learning objectives

  • Map any tool’s personalization, privacy, project rules, automation, memory, and MCP to the 02-1 layer model.
  • State each tool’s project-level rule file name and location, and judge the scope and priority order it applies.
  • Find each tool’s privacy / training opt-out switch and know whether the default is on or off.
  • Use AGENTS.md to share one set of project rules across multiple tools, and explain the trade-offs between it and each tool’s proprietary file.
Currency disclaimerThe setting names, file names, and mechanisms below were verified as of 2026-06; see sources at the end. All tools update frequently; recheck against official docs before you act. File names and directory paths are fast-moving facts — this unit provides a mapping framework, not a list you can copy forever.

1. Framework first, then the four main tools

Every tool’s configuration surface revolves around the same six concepts. Pin them down first; everything after is filling in the columns. The test is simple: when you pick up a new tool, ask what fills each of these six cells and what the defaults are. If you can fill the whole table you understand its configuration surface. Any cell you cannot fill is documentation you have not read yet. The next four sections map each tool to these six cells and call out the differences; Section 5 briefly covers Cursor as a contrast.

2. OpenAI: ChatGPT (consumer) and Codex (CLI)

OpenAI’s configuration surface runs on two tracks: ChatGPT is account settings plus a GUI; Codex is files plus a CLI. The concepts align, but the interfaces are completely different. ChatGPT personalization goes through Settings → Personalization → Custom Instructions, with two fields (“about you” and “how you’d like responses”), and requires enabling Enable customization to take effect. Tone is a separate dropdown under Base style and tone (Default / Professional / Friendly / Candid / Quirky / Efficient / Nerdy / Cynical), which corresponds to Claude’s response style concept. Memory splits into two independently toggleable parts: Saved Memories (individually viewable and deletable) and Reference chat history (drawing on past conversations), at Settings → Personalization → Manage memories. This is one notable difference from Claude: ChatGPT’s memory accumulates automatically on the account side. Its behavior differs from Claude’s memory mechanism — do not assume the semantics are the same. Projects provide project-level instructions and files, with a project-only memory option (selectable only when the project is first created) to isolate that project’s memory from the global pool. Custom GPTs assemble shareable customized assistants through the Configure tab’s Instructions / Knowledge / Capabilities / Actions fields. Privacy opt-out: Settings → Data Controls → “Improve the model for everyone” toggle. Individual conversations can use Temporary Chat to stay out of history. Team / Enterprise plans default to no training and can negotiate ZDR (zero data retention). Consumer tier defaults to “on” (conversations may be used to improve the model) — you have to turn it off yourself. Codex stores all settings in two file types: the AGENTS.md family holds project instructions; config.toml holds behavioral configuration in TOML format. How they are read and layered:
  • Project instructions (AGENTS.md): placed in the project root. Codex scans from the project root (typically the git root) down to the current working directory, concatenating every AGENTS.md found along the way. Entries closer to the current directory appear later and therefore override earlier ones. (At the same level, AGENTS.override.md is read before AGENTS.md; project_doc_fallback_filenames can specify alternate names.) A global copy at ~/.codex/AGENTS.md applies to all your projects.
  • Behavioral configuration (config.toml): precedence from high to low is IT-managed requirements.toml (enterprise-enforced constraints the user cannot override, such as prohibiting approval_policy: never) → CLI flags → project-local .codex/config.toml (only loaded when the project is trusted; an unknown cloned project does not get this layer read) → named profile (switched with --profile <name>) → ~/.codex/config.toml applying to all projects. The entire ~/.codex directory can be relocated with the CODEX_HOME environment variable.
  • Most commonly used keys:
    • model: which model to use by default
    • approval_policy: when to pause and ask (untrusted asks at every step, on-request asks when appropriate, never never asks; a granular object allows finer control)
    • sandbox_mode: what the agent can touch (read-only, workspace-write for writes within the project, danger-full-access for unrestricted access)
    • [mcp_servers.<id>]: connect MCP servers
    • [hooks] (stable, enabled by default; the old codex_hooks toggle name is deprecated — to disable, set hooks = false under [features]): lifecycle hooks
  • Billing: either log in with a ChatGPT account (which includes a 5-hour usage window) or supply your own API key (billed per token).

Codex configuration directory (~/.codex/)

3. Google: Gemini (consumer) and Antigravity (developer platform)

Same two-track structure. Gemini is account plus GUI; Antigravity is files plus IDE/CLI. Gemini personalization uses Gems (custom personas with Name / Instructions / Knowledge fields, connectable to Drive and NotebookLM). The account-side Personal context (Settings) contains three parts: Memory (learns from past conversations), Instructions for Gemini (standing instructions, corresponding to Claude’s Instructions for Claude), and Connected Apps (Gmail / Calendar, etc.). Privacy opt-out: the “Keep Activity” toggle (defaulting to on for users 18 and over), with auto-delete periods of 3 / 18 (default) / 36 months available; turning it off stops use for training. Workspace accounts are admin-controlled and personal toggles may be overridden by organizational policy. Antigravity is Google’s agentic development platform covering four surfaces under one brand: desktop app (Antigravity 2.0), IDE, CLI (agy), and SDK, each with a different configuration surface. The base model is Gemini 3.5 Flash (as of 2026-06, [9]). It is a different product from Gemini CLI but shares a global rule file at ~/.gemini/GEMINI.md (see the conflict warning at the end of this section). Rules are divided into two layers:
  1. Global rules: ~/.gemini/GEMINI.md, applying to all workspaces.
  2. Workspace rules: .agents/rules/*.md inside the project (note the plural .agents/, which is the current official default; the old singular .agent/rules/ remains backward-compatible). The workspace GEMINI.md and AGENTS.md are also read. Rules are plain Markdown with four activation modes: Manual / Always On / Model Decision / Glob. The strict priority order between GEMINI.md and AGENTS.md is not declared on the official page.
Placement varies by surface ([9], per antigravity.google/docs):
  • Skills: shared across all tools at ~/.gemini/skills/<name>/SKILL.md; CLI-only global at ~/.gemini/antigravity-cli/skills/; workspace always at .agents/skills/ (backward-compatible with .agent/skills/).
  • MCP: official config at ~/.gemini/config/mcp_config.json (shared across IDE and CLI globally); CLI workspace can use .agents/mcp_config.json.
  • Hooks: hooks.json in .agents/ (workspace) or ~/.gemini/config/ (global); events include PreToolUse / PostToolUse / PreInvocation / PostInvocation / Stop.
  • CLI (agy) settings: ~/.gemini/antigravity-cli/settings.json and keybindings.json.
  • Workflows: invoked as /workflow-name, created through the IDE Customizations panel; the exact on-disk path is subject to Antigravity official documentation.
Antigravity privacy opt-out: the Enable Telemetry toggle (Settings → Account) is a different switch in a different product from the Gemini consumer “Keep Activity” toggle above — do not conflate them.
Antigravity rule directory has been renamed to plural; verify against your versionThe current official default is plural .agents/ (rules / skills / mcp_config.json all live there). The old singular .agent/ is still backward-compatible but is not the default. Early third-party articles and older versions of this knowledge base incorrectly recorded “official uses singular” — this has been corrected to follow the official page. ~/.gemini/GEMINI.md is known to conflict when both Gemini CLI and Antigravity write to it (GitHub issue #16058, closed as not planned). The Antigravity official site antigravity.google/docs is a client-side-rendered SPA and its content cannot be retrieved by ordinary crawling. The facts in this section are based on first-hand official page content obtained via playwright rendering (as of 2026-06). Always treat the official docs for your installed version as the final authority.

Antigravity configuration directory (~/.gemini/)

4. GitHub Copilot CLI (the new standalone copilot binary)

Identity clarificationThis section covers only the new standalone local copilot CLI (npm @github/copilot), which is a separate product line from the older gh copilot extension (which only handles suggest / explain). VS Code’s Copilot Chat and the local CLI do not share a configuration mechanism: the CLI reads ~/.copilot/, while VS Code Copilot Chat reads chat.* workspace settings (such as chat.instructionsFilesLocations), with different file paths and loading behavior. VS Code Copilot Chat is not covered in this section.
Copilot CLI’s configuration surface is almost entirely file-based and is carved up by scope with unusually fine granularity ([3]). The default root is ~/.copilot/, overridable with COPILOT_HOME or --config-dir; COPILOT_CACHE_HOME controls the cache separately.
  • Local instructions: ~/.copilot/copilot-instructions.md (single file at the ~/.copilot/ root), effective for all sessions on that machine.
  • Repository-wide instructions: .github/copilot-instructions.md, applied across the whole repo.
  • Path-specific instructions: .github/instructions/NAME.instructions.md, with frontmatter using applyTo as a glob to control scope, and optional excludeAgent. This is where Copilot is more granular than most tools: rules can be bound precisely to specific paths.
  • Agent instruction layer: root AGENTS.md (primary), AGENTS.md files in cwd or in directories listed in COPILOT_CUSTOM_INSTRUCTIONS_DIRS (additional), and root CLAUDE.md / GEMINI.md as AGENTS.md alternatives. All matching instruction files are used together with no strict priority order; Copilot’s resolution of conflicts is non-deterministic — avoid contradictions.
  • Automation:
    • Personal / project agents: user layer ~/.copilot/agents/<name>.agent.md; project layer .github/agents/<name>.agent.md (same name at project level overrides user level).
    • Personal / project skills: user layer ~/.copilot/skills/<n>/SKILL.md; project layer .github/skills/<n>/SKILL.md (same name at project level overrides user level).
    • Hooks: user layer ~/.copilot/hooks/ or inline in config.json; project layer .github/hooks/; both layers are merged (not overriding).
  • MCP: user layer ~/.copilot/mcp-config.json; project layer .mcp.json / .github/mcp.json / .vscode/mcp.json (project layer overrides user layer when names match).
  • Cloud Coding agent: tasks dispatched via Issue or @copilot are a separate product line whose execution environment is configured by .github/workflows/copilot-setup-steps.yml. The local CLI does not use this path.

5. Cursor (brief mention)

Cursor is a third-party IDE (developed by Anysphere, not a model vendor). Rule format is .cursor/rules/*.mdc (note: plain .md files are ignored — it must be .mdc). It also reads AGENTS.md as a simplified alternative. The older .cursorrules has been marked for deprecation. For detailed format and ignore-file differences see Cursor’s official documentation [4]; this Playbook does not go deeper.

6. AGENTS.md: the shared rule file across tools

AGENTS.md is the open standard for converging each tool’s proprietary rule files into one. It is a standard for the project rules layer, not the personalization layer. Treating it as the “shared baseline file” across tools is the framing least likely to cause misuse. Key points:
  • Plain Markdown with no enforced schema; placed at the repository root. Monorepos can have multiple levels: files closer to the file being edited take precedence.
  • Adoption: Codex, Cursor, Copilot, Gemini CLI, Jules, Devin, Amp, VS Code, and more than twenty other tools support it natively; over 60,000 open-source projects have adopted it (as of 2026-06) [5].
  • Governance: coordinated by the Agentic AI Foundation (AAIF) under the Linux Foundation. AGENTS.md is one of three founding projects — contributed by OpenAI; the other two are Anthropic’s MCP and Block’s goose [6]. Standard site: agents.md.
How each tool reads AGENTS.md:
  • Native support: Codex, Cursor, Copilot, Gemini CLI, and others treat AGENTS.md as the project rules entry point. Each also has its own proprietary file (GEMINI.md, .cursor/rules/, .github/copilot-instructions.md) for tool-specific overrides or additions.
  • No native support: Claude Code. AGENTS.md is not on its read list. To use the same baseline, add @AGENTS.md inside CLAUDE.md to import it [8]. Claude’s “proprietary file” is CLAUDE.md itself — it is the only entry point Claude Code reads.
AGENTS.md is the baseline, not the replacement: tool-specific rules still live in each tool’s proprietary file. For a concrete walkthrough of extracting a baseline and validating shared reads, see Section 7.

Cross-tool comparison table (as of 2026-06)

Rows are concepts; columns are tools; Claude column is first. All four main tools use CLI as the comparison axis. The OpenAI column uses Codex as primary with ChatGPT as supplementary; the Google column uses Antigravity as primary with Gemini as supplementary. Antigravity is primarily an IDE interface (Electron / VS Code-derived); CLI pairings are concept-level only — for exact file names and paths see Section 3. Cursor is a third-party IDE listed with brief notes only.

Hands-on: fill in the six concepts for Claude, then map to another tool

Scenario: you use Claude and want to evaluate migrating to another tool, or running both in parallel. The approach has three steps: fill in Claude’s six concept cells with concrete values as a source template; map each cell to the target tool; then extract the overlapping project rules into AGENTS.md so the other tool can read them too. Step one: fill in the six cells from Section 1 with Claude’s real settings. This becomes your mapping template.
Claude six-concept fill-in: using Claude Code as the example
Step two: take that template and map each cell to the target tool. Using a migration to Codex as an example — the concepts stay the same, only the file names and locations change.
Claude to Codex cell-by-cell mappingAfter completing the mapping you will find only two things differ: Codex centralizes configuration in config.toml, while Claude uses settings.json.
Stop there. The Claude entry point remains CLAUDE.md at all times — you do not need to restructure it to enable cross-tool shared reads.

Common pitfalls

  • Assuming same-named features behave identically. Each tool’s Memory is the biggest trap: Claude’s memory, ChatGPT’s Saved Memories, and Gemini’s Memory differ in what they store, what triggers them, and whether they can be disabled. Seeing a familiar word and applying your old mental model will cause privacy and behavioral problems. Mapping the concept is fine; assuming the semantics are identical is not.
  • Maintaining multiple proprietary files on a tool that supports AGENTS.md. Duplicate content drifts. Every copy ends up half-right and half-wrong. Decide which file is the baseline (usually AGENTS.md) and have the others point to it.
  • Confusing Cursor’s two ignore files. .cursorignore completely blocks AI access. .cursorindexingignore only excludes indexing — files can still be read. Putting secrets in the wrong file means you think you’ve blocked access when you haven’t.
  • Assuming consumer tiers default to no training. ChatGPT and Gemini’s consumer plans typically default to using conversations to improve the model. You have to opt out yourself. Do not apply enterprise plan defaults to personal accounts.
  • Copying fast-moving file names and paths verbatim. Things like Antigravity’s .agent/ vs .agents/, or the location of Codex’s config.toml, change with versions. This unit provides a mapping framework — verify against your version’s official docs before acting.

Self-check

Can you do the mapping?
  1. Take the non-Claude tool you use most often and fill in all six concept cells from Section 1: where are personalization, project rules, memory, privacy opt-out, automation, and MCP configured? Which cell can you not fill?
  2. Is your tool’s privacy opt-out switch on or off by default? What is the current state of your account?
  3. If you wanted Claude and that tool to share the same project rules, where would you put the baseline, and what would you keep in each tool’s proprietary file?
  4. Does your repo contain two rule files with overlapping content? Are they consistent right now?

Sources and further reading

Factual claims are grounded in official documentation; fast-changing items are annotated as of 2026-06.