- Book: LLM Observability Pocket Guide
- Also by me: Thinking in Go (2-book series) — Complete Guide to Go Programming + Hexagonal Architecture in Go
- My project: Hermes IDE | GitHub — an IDE for developers who ship with Claude Code and other AI coding tools
- Me: xgabriel.com | GitHub
Your agent just ignored a rule you know you wrote down. Before you rewrite the prompt, answer two questions: which file did it actually read, and where did it write down what it did?
The answers are less obvious than they look, because the agents read each other's files. If you have a ~/.claude/CLAUDE.md and no ~/.config/opencode/AGENTS.md, OpenCode loads your Claude file as its global rules (OpenCode rules docs). GitHub Copilot CLI reads AGENTS.md, CLAUDE.md and GEMINI.md in your repo and combines them, and its docs define no precedence between them. Claude Code reads AGENTS.md since v2.1.277, but by default only when there is no CLAUDE.md, .claude/CLAUDE.md or CLAUDE.local.md on the path.
| Instructions file | Claude Code | Codex | Copilot CLI | OpenCode |
|---|---|---|---|---|
AGENTS.md in the repo |
Only if no CLAUDE.md or CLAUDE.local.md on the path |
Yes | Yes, combined | Yes, wins over CLAUDE.md
|
CLAUDE.md in the repo |
Yes | Only as a fallback name you configure | Yes, combined | Only if no AGENTS.md
|
~/.claude/CLAUDE.md |
Yes | Not listed | Not listed | If no global OpenCode AGENTS.md
|
Every path below is from the vendor's own docs or repository as of October 14, 2026, with commands you can paste. Run them from your repo root; the JSON ones need jq.
Claude Code
Settings stack in five layers, highest first: managed settings, claude --settings, .claude/settings.local.json, .claude/settings.json, then ~/.claude/settings.json (settings docs). A separate file, ~/.claude.json, holds your sign-in, per-project trust decisions and your personal MCP servers. MCP servers have three scopes: user and local live in ~/.claude.json, project scope lives in .mcp.json at the repo root (MCP docs).
Instructions load from ~/.claude/CLAUDE.md and from CLAUDE.md or .claude/CLAUDE.md in your working directory and every directory above it, plus a gitignored CLAUDE.local.md. The project files are concatenated, not overridden, and the file closest to where you launched is read last. Files in subdirectories load on demand. Adding a CLAUDE.local.md to a repo that only had an AGENTS.md quietly stops Claude from reading the AGENTS.md. Auto memory, the notes Claude writes itself, sits in ~/.claude/projects/<project>/memory/ with a MEMORY.md index, and only its first 200 lines or 25KB load at startup (memory docs).
Transcripts are one JSONL file per session at ~/.claude/projects/<project>/<session>.jsonl, with subagent transcripts in a <session>/subagents/ folder beside it. The folder name is your working directory path with every character other than a letter or digit turned into -. Debug logs go to ~/.claude/debug/ when you start with --debug. Claude Code deletes these files after cleanupPeriodDays, 30 days by default, with exceptions the docs list, such as sessions continued in Claude Desktop (.claude directory docs).
cat ~/.claude/settings.json
cat .claude/settings.json .claude/settings.local.json
jq '.mcpServers // {} | keys' ~/.claude.json
jq '.mcpServers // {} | keys' .mcp.json
claude mcp list
# newest transcript for this directory
d=~/.claude/projects/$(pwd | sed 's/[^A-Za-z0-9]/-/g')
f=$(ls -t "$d"/*.jsonl | head -1)
tail -n 3 "$f" | jq .
Inside a session, /context lists the memory files that loaded at launch and /memory opens them. For a log of which instruction files loaded and why, use the InstructionsLoaded hook; it skips an AGENTS.md that Claude reads directly.
One warning before you paste a transcript into a bug report. The docs say transcripts are plaintext and not encrypted, and if a tool reads a .env file, that value is now in the .jsonl file.
Four agents, four sets of drawers. Same kinds of papers, different places to look.
Codex
Codex keeps its state under CODEX_HOME, which defaults to ~/.codex (advanced config). Config precedence, highest first: CLI flags and --config overrides, project .codex/config.toml files from the repo root down to your current directory, a --profile file, ~/.codex/config.toml, cloud-managed defaults, then /etc/codex/config.toml. Project .codex/ layers load only when you trust the project.
Instructions come from ~/.codex/AGENTS.override.md or, if that is absent, ~/.codex/AGENTS.md. Then Codex walks from the project root down to your working directory and takes at most one file per directory: AGENTS.override.md, then AGENTS.md, then any names in project_doc_fallback_filenames. It stops adding files once the total reaches project_doc_max_bytes, 32 KiB by default (AGENTS.md docs). Anything past that cap never reaches the model.
MCP servers are [mcp_servers.<name>] tables in the same config.toml, user or trusted project (MCP docs). Local memories are off by default; when you turn them on they live in ~/.codex/memories/ (memories docs). Logs default to $CODEX_HOME/log (config reference). Session transcripts are JSONL rollout files under $CODEX_HOME/sessions/YYYY/MM/DD/rollout-*.jsonl. The Codex docs don't describe that layout. It comes from a 2025 feature request, openai/codex issue #2288, so treat it as observed behaviour rather than a documented contract. The docs do mention history.jsonl in the same home folder.
cat ~/.codex/config.toml
cat .codex/config.toml # read only in trusted projects
ls ~/.codex/AGENTS.override.md ~/.codex/AGENTS.md
codex mcp list
# newest rollout: the date folders sort by name
f=$(find ~/.codex/sessions -name 'rollout-*.jsonl' | sort | tail -1)
tail -n 3 "$f" | jq .
ls ~/.codex/log
Two built-in commands do more than any cat (command reference). /debug-config in the TUI prints the config layer order and policy sources, "to debug why an effective setting differs from config.toml". codex debug prompt-input renders the exact prompt input the model sees as JSON, which answers "did it read my AGENTS.md" directly. One more trap: codex resume --last only looks at sessions from your current directory unless you add --all.
GitHub Copilot CLI
Everything user-level lives in ~/.copilot (config directory reference). settings.json is the primary config; config.json is internal state you don't edit. Repo settings go in .github/copilot/settings.json, personal overrides in .github/copilot/settings.local.json, and Copilot CLI also reads a subset of .claude/settings.json. Setting COPILOT_HOME moves the whole folder.
Instructions: .github/copilot-instructions.md, path-scoped .github/instructions/**/*.instructions.md files that apply when their applyTo glob matches, AGENTS.md, CLAUDE.md or .claude/CLAUDE.md, GEMINI.md, and your own ~/.copilot/copilot-instructions.md (custom instructions docs). Copilot combines all of them and drops identical duplicates. GitHub defines no general precedence order between them, and its only guidance is to avoid conflicting instructions.
User MCP servers are in ~/.copilot/mcp-config.json under mcpServers. Project servers in .mcp.json or .github/mcp.json take precedence, and /mcp show NAME shows one server's status and tools (MCP docs). Each session gets a folder in ~/.copilot/session-state/ holding an events.jsonl event log plus plans and checkpoints. Each session also writes a process-{timestamp}-{pid}.log in ~/.copilot/logs/.
cat ~/.copilot/settings.json .github/copilot/settings.json
jq '.mcpServers // {} | keys' ~/.copilot/mcp-config.json
ls .mcp.json .github/mcp.json 2>/dev/null
cat ~/.copilot/copilot-instructions.md
s=$(ls -t ~/.copilot/session-state | head -1)
tail -n 3 ~/.copilot/session-state/"$s"/events.jsonl | jq .
ls -t ~/.copilot/logs | head -1
OpenCode
Config merges, later wins: remote org defaults from .well-known/opencode, then ~/.config/opencode/opencode.json, then the file in OPENCODE_CONFIG, then opencode.json in the project root, then .opencode directories and OPENCODE_CONFIG_CONTENT. Managed config from your admin overrides all of them (config docs). MCP servers sit under the mcp key. The files can be JSONC, with comments, which is why the commands below use opencode mcp list and not jq.
Rules load from AGENTS.md found by walking up from your directory, with CLAUDE.md as the fallback, then ~/.config/opencode/AGENTS.md, then ~/.claude/CLAUDE.md. The first match wins in each category. OPENCODE_DISABLE_CLAUDE_CODE=1 turns off all .claude support, and the instructions field in opencode.json adds more files or URLs (rules docs).
Data lives in ~/.local/share/opencode/: auth.json with your API keys and OAuth tokens, and a log/ folder that keeps the 10 most recent files (troubleshooting docs). Since v1.2.0, sessions are no longer flat files: that release migrated them into one SQLite database, opencode.db, in the same folder (v1.2.0 release notes). Use the CLI to read them rather than the schema (CLI docs).
cat ~/.config/opencode/opencode.json opencode.json
ls ~/.config/opencode/AGENTS.md ~/.claude/CLAUDE.md
opencode mcp list
ls ~/.local/share/opencode/
ls -t ~/.local/share/opencode/log | head -1
opencode session list --format json -n 5
# ID: a session id from the list above
opencode export "$ID" --sanitize > session.json
--sanitize redacts sensitive transcript and file data. Skim the JSON anyway before you attach it to an issue, because the docs don't promise the redaction catches everything. Never attach auth.json. When OpenCode won't start, opencode --print-logs --log-level DEBUG prints the log to your terminal.
One repo, several worktrees, and a separate trail of notes at the end of each branch.
Which session touched that file?
When a file changed and you don't know which session did it, grep the transcripts for its path. That works for three of the four:
grep -l 'src/auth.ts' ~/.claude/projects/*/*.jsonl
grep -rl 'src/auth.ts' ~/.codex/sessions
grep -l 'src/auth.ts' ~/.copilot/session-state/*/events.jsonl
OpenCode keeps sessions in SQLite, so export the session with opencode export and grep the JSON.
This gets more useful once you run agents in parallel. I build Hermes IDE, so weigh this with that in mind. Hermes runs Claude Code, Codex, Copilot CLI, OpenCode and the rest each in its own real terminal, with the agent's own interface and sign-in, and a task can get its own hermes/<name> branch and worktree. Each agent runs as it would anywhere else, so every path above still applies. Worktrees change a few answers, though.
A Claude Code transcript folder is named after the working directory, so sessions in a worktree land in a different ~/.claude/projects/ folder than sessions in your main checkout. Auto memory is the exception: its folder comes from the git repository, so all worktrees of one repo share it. A gitignored CLAUDE.local.md exists only in the worktree where you created it (memory docs), and the same goes for any untracked AGENTS.override.md, because a new worktree holds tracked files only. And codex resume --last from the main checkout won't find a session you ran in a worktree unless you add --all.
Hermes keeps its own record alongside these files. Every agent turn is saved, so you can diff or restore one turn, and the per-session spend is what the agent reports, or an estimate from its transcript marked as estimated (README). It is free to download and source-available under BSL 1.1, and it runs on macOS, Windows and Linux. It isn't affiliated with Anthropic, OpenAI or any other agent vendor. Download it here.
If this was useful
A transcript is a trace you didn't have to instrument: every prompt, tool call and result, already on disk. If you want to turn files like these into proper tracing and evals for your own LLM features, the LLM Observability Pocket Guide is the short version of how to pick the tools. And if this cheat sheet saved you a search, a star on Hermes IDE helps other developers find it.
Top comments (0)