Context and Memory

Context and Memory

Codex runs against a large context window and keeps its session in a process you control. ChatGPT Web does neither: the window is smaller than most real tasks, and when it fills — or when you open a new chat — the plan and everything learned along the way are gone, with no sign to the model they ever existed. Codexify attacks both halves.

---

Spend the window on less

Model-visible tool results are bounded by output.maxToolOutputTokens (10,000 approximate tokens by default), independently for textual content and model-visible structuredContent. Component-only result _meta, such as the show_diff widget payload, stays outside that model-context ceiling. Tools with semantic paging limits also say how to continue:

(showing lines 1-1000 of 4820 — call again with offset=1000 for the rest)

That line matters as much as the cap. Silent truncation reads as "that was the whole file", which is worse than no cap at all. read_file has a byte ceiling as well as a line one, because a minified bundle is a single line several megabytes long that a line cap alone would hand back in full. grep separately bounds match count, context, and individual long lines; exec_command / write_stdin clamp caller-requested output budgets to server policy; run_command drains stdout/stderr through bounded head/tail buffers. The caps live in the output block — see Configuration.

Keep what would be expensive to rediscover

• remember creates one keyed note and refuses a key that already exists.
• update_memory_note replaces an existing note and refuses a missing key.
• forget_memory_note deletes an existing note.
• recall hands back the notes and the current plan.
• update_plan persists the plan too, so it survives the conversation that made it.

Creation, replacement, and deletion are separate operations, so an empty string is no longer overloaded as an implicit delete and each operation can carry the correct safety classification.

Where state lives

Task state lives in:

~/.codexify/projects/<name>-<hash>/memory.json

keyed by the absolute active project root. Nothing is written into the repository you pointed the server at, and two checkouts of the same repo do not share notes. Multi-project conversations share task state only when they select the same canonical project root.

Configure it with the memory block:

Key	Default
enabled	true	false turns persistence off entirely.
dir	~/.codexify/projects/<name>-<hash>	Outside the repo by default. In multi-project mode an explicit dir becomes a base directory with a hashed child per project.
maxBytes	16384	Budget for all notes together. A note over it is rejected, not silently evicted.

ChatGPT project bindings (multi-project)

Separate from task state, project bindings live under:

~/.codexify/conversation-projects/<access-root-hash>/<conversation-hash>.json

The raw openai/session value is never written — only its SHA-256-derived key is used as the filename. Each small record holds the canonical access root and selected project root. Delete this directory to forget all conversation bindings. A missing or stale project fails closed rather than silently rebinding the conversation elsewhere. Bindings stay enabled even when memory.enabled is false.

How saved state reaches a new chat

• Single-project mode: instructions is rebuilt for every MCP session, so a new conversation opens with the saved plan and notes already in front of it, under a ## Saved state heading between the environment and AGENTS.md.
• Multi-project mode: initialize-time instructions stay project-neutral (the conversation identifier arrives on tool calls, after initialize). Calling get_agent_brief restores an existing binding automatically; for a new conversation it says set_project_root is required. After binding, get_agent_brief returns the environment, saved state, skills, and AGENTS.md for the selected project.

If the client ignores instructions, one recall gets the same saved state after selection.

The division of labour

Keep this straight:

AGENTS.md is what is true of the project — it belongs in the repo. Notes are what is true of the task in flight — they belong here.

See AGENTS and Skills for the project side.

---

See also

• How It Works — where bounding and persistence sit in the request lifecycle.
• Tools Reference — remember, update_memory_note, forget_memory_note, recall, update_plan.
• Configuration — the memory and output blocks.