Full Comparison of Configuration and Log Storage Paths Across Four Major AI Coding Agents

Your agent just ignored a rule you clearly wrote down. Before rewriting the prompt, answer two questions: which file did it actually read? And where did it write its own behavior?

The answer is more complicated than it looks on the surface, because these agents read each other's files. If you have ~/.claude/CLAUDE.md but no ~/.config/opencode/AGENTS.md, OpenCode will load your Claude file as global rules. GitHub Copilot CLI merges and reads AGENTS.md, CLAUDE.md, and GEMINI.md from the repository, and its documentation does not define the priority among these three. Since v2.1.277, Claude Code also reads AGENTS.md, but by default only when there is no CLAUDE.md, .claude/CLAUDE.md, or CLAUDE.local.md on the path.

Below is a complete comparison of where these four tools store configuration, memory, and logs. All paths come from each vendor's official documentation or repository.

Loading Rules for Instruction Files

Instruction file priority is the easiest place to step on a landmine. The table below summarizes the actual behavior of three common instruction files across the four tools:

Instruction File	Claude Code	Codex	Copilot CLI	OpenCode
Repository AGENTS.md	Only when there is no CLAUDE.md or CLAUDE.local.md on the path	Reads	Merges and reads	Reads, and takes priority over CLAUDE.md
Repository CLAUDE.md	Reads	Only as a configurable fallback name	Merges and reads	Only when there is no AGENTS.md
~/.claude/CLAUDE.md	Reads	Not listed	Not listed	When there is no global OpenCode AGENTS.md

Copilot CLI is the only tool that explicitly defines "no priority"—it merges all instruction files it finds, removing only exact duplicates. GitHub's only recommendation is: avoid writing conflicting instructions. This means that when maintaining multiple instruction files in Copilot CLI, you need to ensure consistency yourself.

Why do Agent rule files read across each other?

The cross-reading behavior across multiple vendors stems from an early industry convention: AGENTS.md was once promoted as a universal cross-tool instruction file name. OpenCode, Codex, and Copilot CLI all adopted this convention, and then each layered its own historical file names (CLAUDE.md, GEMINI.md) on top of it. The result is that the same rule may be parsed by multiple tools, and each tool's priority determination logic is independently decided by its own implementer.

When multiple files exist at the same time, what ultimately enters the model context is often the "concatenated result" rather than the "winning result." This means that when troubleshooting abnormal Agent behavior, you should not only check the file you most recently modified, but confirm which files were actually loaded at startup and in what order they were concatenated. This is also the reason diagnostic commands like the InstructionsLoaded hook and /debug-config exist.

Claude Code

Claude Code settings are divided into five layers, from highest to lowest: managed settings, claude --settings, .claude/settings.local.json, .claude/settings.json, and finally ~/.claude/settings.json. There is also a separate file, ~/.claude.json, which stores login information, project trust decisions, and personal MCP servers.

MCP servers have three scopes: user-level and local-level are stored in ~/.claude.json, and project-level is stored in .mcp.json at the repository root.

Instructions are loaded from ~/.claude/CLAUDE.md as well as CLAUDE.md or .claude/CLAUDE.md in the working directory and all parent directories, plus a git-ignored CLAUDE.local.md. Project files are concatenated rather than overridden, and the file closest to the startup location is read last. An easily overlooked trap: adding a CLAUDE.local.md in a repository that only has AGENTS.md will silently cause Claude to stop reading AGENTS.md.

Automatic memory is stored under ~/.claude/projects/<project>/memory/, with a MEMORY.md index, and only the first 200 lines or 25KB are loaded at startup.

Session records are one JSONL file per session, located at ~/.claude/projects/<project>/<session>.jsonl. The folder name is your working directory path, with all non-alphanumeric characters replaced by hyphens. By default, these files are cleaned up after 30 days.

During a session, /context lists the memory files loaded at startup, and /memory opens them. To see which instruction files were loaded and why, you can use the InstructionsLoaded hook.

Security reminder: The official documentation explicitly states that session records are plaintext and unencrypted. If a tool has read a .env file, its values are now in the JSONL file. Think twice before pasting session records into a bug report.

The boundary between MCP and settings

MCP (Model Context Protocol) is an open protocol proposed by Anthropic for letting models call external tools and data sources in a standardized way; for an Agent, an MCP server is simply a set of capabilities it can dynamically invoke during a session.

The reason MCP configuration is stored in three places in Claude Code is that the three have different scopes: user-level applies to all your projects, project-level is committed with the repository and shared with the team, and local-level belongs only to your own machine and is usually git-ignored. Understanding this layering is key to troubleshooting "why this tool works on my machine but errors in CI"—most likely the user-level versus project-level scope does not match.

Codex

Codex stores state under CODEX_HOME, which defaults to ~/.codex. Configuration priority, from highest to lowest, is: CLI flags and --config overrides, project-level .codex/config.toml, --profile files, ~/.codex/config.toml, cloud-managed defaults, and finally /etc/codex/config.toml. Project-level .codex/ is loaded only when the project is trusted.

Instructions come from ~/.codex/AGENTS.override.md; if it does not exist, Codex reads ~/.codex/AGENTS.md. Then Codex walks from the project root down to the working directory, taking at most one file per directory. It stops adding files when the total reaches project_doc_max_bytes (default 32KB). Content beyond the limit never reaches the model.

MCP servers are [mcp_servers.<name>] tables in the same config.toml. Local memory is off by default, and when enabled is stored in ~/.codex/memories/. Session records are JSONL rollout files located at $CODEX_HOME/sessions/YYYY/MM/DD/rollout-*.jsonl—note that this layout comes from a 2025 feature request (openai/codex issue #2288), and is observed behavior rather than a documented contract.

Two built-in commands are more useful than any cat: /debug-config prints the configuration layer order and policy sources; codex debug prompt-input renders the exact prompt input the model sees, directly answering "did it read my AGENTS.md?"

GitHub Copilot CLI

User-level configuration is all located in ~/.copilot. settings.json is the main configuration, and config.json is internal state, which should not be edited manually. Repository settings go in .github/copilot/settings.json, and personal overrides go in .github/copilot/settings.local.json. Setting the COPILOT_HOME environment variable can move the entire folder.

Instruction files come from many sources: .github/copilot-instructions.md, path-matched .github/instructions/**/*.instructions.md, AGENTS.md, CLAUDE.md or .claude/CLAUDE.md, GEMINI.md, and your own ~/.copilot/copilot-instructions.md. Copilot merges them all, removing exact duplicates.

User-level MCP servers are under the mcpServers key in ~/.copilot/mcp-config.json. Project-level servers are in .mcp.json or .github/mcp.json, and take priority over user-level. Each session has a folder under ~/.copilot/session-state/, containing an events.jsonl event log as well as plans and checkpoints.

OpenCode

OpenCode configuration is merged, with the latter winning: remote organization defaults, ~/.config/opencode/opencode.json, the file specified by OPENCODE_CONFIG, opencode.json at the project root, the .opencode directory, and OPENCODE_CONFIG_CONTENT. Administrator-managed configuration overrides everything. Configuration files can be JSONC with comments.

Rule loading starts by searching upward for AGENTS.md, with CLAUDE.md as a fallback, then ~/.config/opencode/AGENTS.md, and finally ~/.claude/CLAUDE.md. The first match in each category wins. Setting OPENCODE_DISABLE_CLAUDE_CODE=1 disables all .claude support.

Data is stored in ~/.local/share/opencode/: auth.json contains API keys and OAuth tokens, and the log/ folder keeps the last 10 files. Since v1.2.0, sessions are no longer flat files—that version migrated them into a SQLite database, opencode.db. Reading sessions should use the CLI rather than querying the database schema directly. opencode export <id> --sanitize sanitizes sensitive content, but the documentation does not promise that sanitization covers everything, so you should still check it yourself before attaching it to an issue.

The impact of migrating from flat files to SQLite

In early OpenCode, sessions were standalone files on disk and could be grepped directly; after v1.2.0 they were consolidated into opencode.db, which has two practical consequences: first, you can no longer use grep -r to search across sessions, and must go through the CLI channel via opencode export <id>; second, the database schema is an internal implementation and the official project has not promised it is stable, so directly connecting to the database for queries may fail after a version upgrade.

In addition, OpenCode follows the XDG directory specification (~/.config for configuration, ~/.local/share for data), which differs from Claude Code and Codex stuffing everything into ~/.claude and ~/.codex. When writing scripts for backup or cleanup, you need to be aware that the path conventions of the two are not consistent.

Which session changed that file?

When a file has been modified and you do not know which session did it, you can grep the session records directly. This works for three of the four tools: Claude Code, Codex, and Copilot CLI session records are all directly searchable JSONL files. Because OpenCode uses SQLite, you need to export first with opencode export and then search.

This trick is especially useful when running multiple Agents in parallel. When each Agent runs in its own worktree, there are several details to note: Claude Code's record folder is named by working directory, so sessions in worktrees land in different folders; but automatic memory is per git repository, and all worktrees of the same repository share it. The git-ignored CLAUDE.local.md exists only in the worktree where it was created. In addition, when codex resume --last is run from the main checkout, it will not find sessions you ran in a worktree unless you add --all.

Key Takeaways

The four mainstream AI coding Agents each have their own systems for storing configuration, memory, and logs, but there is a great deal of cross-reading behavior: OpenCode falls back to Claude's files when it lacks its own global configuration; Copilot CLI merges all instruction files without priority; Claude Code reads AGENTS.md only when there is no CLAUDE.md. Understanding these paths and priority rules is the first step in troubleshooting an Agent that "will not obey." Another point worth watching is the plaintext storage of session records—they are unencrypted plain text and may contain sensitive values from files such as .env.