Skip to content

tell Codex when to use the tools it already has - #40

Merged
ayushcodes10 merged 1 commit into
mainfrom
feat/codex-agents-md
Sep 3, 2026
Merged

tell Codex when to use the tools it already has#40
ayushcodes10 merged 1 commit into
mainfrom
feat/codex-agents-md

Conversation

@ayushcodes10

Copy link
Copy Markdown
Owner

Asked to analyse Eigon, a Codex session with all four MCP tools connected made zero calls.

Measured, not inferred:

codex echo-memory server   0:00.67 CPU over 32:43 elapsed   (0.01s in the window)
read_event                 no query_memory rows at all
facts by agent_id=codex    0

Nothing was broken

Codex had the tools. The server was healthy — I drove the full MCP handshake through ~/.codex/config.toml verbatim and it served all four. agent_id was correct. The write_episode description had just been fixed to fit inside the 2048-char window with its example intact.

What Codex did not have was any instruction, anywhere, about when to call them.

claude-code codex
SessionStart injection ✗ no hook system
Prompt-time recall
Stop gate
Project instruction ✅ SKILL.md ✗ nothing
MCP tool description

install wrote SKILL.md for Claude and a rule for Cursor, and nothing Codex reads. adopt registered its MCP entry and stopped there — which is exactly the "the tools being available is not the same as an agent knowing to call them" gap that install's own docstring names for every other client.

The change

echo-memory install --for codex writes an AGENTS.md section — merged into whatever the project already has, replaced in place on re-run rather than appended. --for all covers claude, cursor and codex together.

The honest caveat

This session's own evidence is that instructions lose to structure: the SessionStart briefing asked 16 times and was ignored 16 times, because Claude Code's file-based memory is a permanent system-prompt section and the briefing was one reminder.

Codex is not that case. There is no competing memory system — there was simply nothing. This moves it from nothing to something, and whether that is enough is now a testable question rather than an unexamined gap.

Testing

420 pass, 5 added: the section is written, existing project text survives, a re-run replaces rather than stacks, hand-edits after install survive a re-run, and --for claude still writes no AGENTS.md.

Asked to analyse Eigon, a Codex session with all four MCP tools connected
made zero calls. Measured, not inferred: its echo-memory server process used
0.01s of CPU across 32 minutes, and read_event recorded no query at all.

Nothing was broken. Codex had the tools, the server was healthy, and the
write_episode description had just been fixed to fit inside its 2048-char
window. What it did not have was any instruction, anywhere, about when to
call them.

Claude Code is told the same thing four ways - the SessionStart briefing, the
UserPromptSubmit recall, the Stop gate, and SKILL.md. Codex has no hook system
at all, so its only surface is AGENTS.md, and install wrote SKILL.md for Claude
and a rule for Cursor while writing nothing Codex reads. adopt registered its
MCP entry and stopped there, which is the "tools being available is not the
same as an agent knowing to call them" gap that install's own docstring names
for every other client.

`echo-memory install --for codex` now writes an AGENTS.md section, merged into
whatever the project already has and replaced in place on re-run rather than
appended. --for all covers claude, cursor and codex together.

Whether an instruction is enough for Codex is now the open question. In Claude
Code an instruction lost to file-based memory that was structurally louder; in
Codex there is no competing system, only silence, so this moves it from nothing
to something.

420 tests pass, 5 added.
@ayushcodes10
ayushcodes10 merged commit 36bdb73 into main Sep 3, 2026
2 checks passed
@ayushcodes10
ayushcodes10 deleted the feat/codex-agents-md branch September 3, 2026 12:17
@github-actions github-actions Bot locked and limited conversation to collaborators Sep 3, 2026
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant