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. 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 — or explicitly resume — the same canonical workspace 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/worktree root, or the persistent scratch marker. 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 project or projectless scratch binding automatically; for a new conversation it says set_project_root is required. After an ordinary selection or exact resumePath continuation, get_agent_brief returns the environment, saved state, skills, and AGENTS.md instructions for that active project/worktree or private scratch workspace.

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

Continue the same workspace in a new conversation

When ChatGPT has refreshed the connector but the current conversation still carries an older tool schema, the setup app exposes Prepare handoff and a copyable continuation prompt.

Prepare handoff asks the current assistant to call recall, update the persistent plan, and create or replace a note named continuation-handoff. The prompt requests the task goal, constraints, completed work, exact workspace, changed files, commits, verification, pending work, and next steps, while excluding credentials, connector setup refs, and raw conversation IDs. This is not an automatic snapshot: the assistant must successfully invoke the memory tools, and the action deliberately does not commit, push, or continue implementation. If project memory is unavailable, it requests a self-contained handoff summary to paste alongside the copied prompt.

The copied prompt tells a new ChatGPT conversation to complete normal connector authorization, then bind the exact existing workspace before any ordinary selection:

{ "resumePath": "/absolute/path/to/the/existing/workspace" }

On success, both conversations resolve to the same absolute root, so the new one receives the same memory namespace and sees every staged, unstaged, and untracked file already there. It then calls get_agent_brief and recall to recover the saved plan and handoff note.

What does not move with the workspace:

• ChatGPT message history and model context;
• resident exec_command process handles, which are in memory and owned by the original conversation identity; and
• diff checkpoints, which are namespaced by conversation/project pair, so the new conversation establishes its own project-open and last-diff baselines.

The original conversation binding remains valid. Treat continuation as a transfer of responsibility, not a concurrency mechanism: do not keep editing the same tree from both conversations. If resumePath validation fails, stop and repair the saved workspace/binding rather than choosing another checkout and thereby landing in a different memory namespace.

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.