Scoped memory management for Codex (global, project, hybrid, and per-thread options)

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #17496
• #16799
• #17715
• #17185

Powered by Codex Action

Potential duplicates detected. Please review them and close your issue if it is a duplicate. Memory read path ignores cwd and injects entire global memory_summary.md into initial context for new sessions #17496 Cross-project, cross-session state leak #16799 Project-scoped chat history in the Codex IDE extension #17715 Project-based Chat Separation (Isolated Chat Context per Project) #17185 _Powered by Codex Action_

These issues seems not to be related.

Scoped memory management: we solved this for multi-agent, same patterns apply

The cross-project contamination problem you describe is exactly what we hit in multi-agent deployments at KinthAI (31 agents, shared OpenClaw gateway). Our solution maps directly to Codex's needs:

Three-tier memory scoping:

1. Global scope — facts about the user that apply everywhere: name, timezone, coding style preferences, language preferences. Stored in memory/global/.

1. Project scope — facts specific to one repo: architecture decisions, key abstractions, naming conventions, deployment config. Stored in memory/project/{project_hash}/. This is the critical missing tier.

1. Session scope — ephemeral context for the current task: what files we're editing, what approach we chose, what we tried and rejected. Discarded at session end unless explicitly promoted.

The key design decision: scope inheritance
When querying memory, the system searches: session → project → global, with project-scoped facts overriding global facts when they conflict. Example: global memory says "use tabs", but project memory says "this repo uses 2-space indent" → project wins.

What we found doesn't work:

• Automatic scope inference (guessing whether a memory is global or project-specific): unreliable. Better to have explicit scope declaration at write time, with a default of project-scoped.
• Per-thread scope without project scope: too granular. Threads within the same project share most context. Thread-specific memories that are not project-level are rare enough to not need their own tier.

Scope management UX:

• memory list --scope project — show what this project "knows"
• memory promote {id} --to global — a project-specific insight that should apply everywhere
• memory demote {id} --to project — a global memory that is wrong for this specific project

This is fundamentally the same problem as multi-tenant memory isolation in agent platforms. We wrote about the architecture: Why Character.AI Forgets You — Persistent Memory Architecture

This is one of the most important memory architecture decisions for coding agents. From building a scoped memory system for 31 concurrent agents:

Four-scope hierarchy works in practice:

1. Global — platform conventions, model preferences, coding style rules that apply everywhere
2. Project — repository-specific knowledge (architecture decisions, dependency choices, naming conventions). This is by far the most important scope — ~70% of useful memories are project-scoped
3. Branch/task — ephemeral context for a specific piece of work ("we decided to use approach X for this PR"). Auto-expires when the branch is merged
4. Session — working scratchpad, never persisted beyond the current interaction

Cross-project contamination is a real problem: We've seen agents apply project A's conventions to project B (e.g., using Python patterns in a Go repo because the agent previously worked on a Python project). The fix is strict scope isolation with explicit inheritance: a project scope inherits from global, but global memories never auto-inherit from project scopes.

Importance scoring with time decay: Not all memories deserve equal weight. We use relevance = importance × (0.95 ^ days_since_stored) to automatically deprioritize stale memories. A memory about a library choice made 6 months ago may no longer be relevant if the dependency has since been replaced. The decay rate should be configurable per scope — global memories decay slowly, session memories don't need decay at all.

Memory compaction across scopes: When the total memory size approaches the context window limit, compact lower-priority scopes first. Progressive compaction: full memory → structured summary with entity references preserved verbatim → one-line digest. A project-scoped memory about "use PostgreSQL for the auth service" must preserve that exact entity reference even through aggressive compaction.

Conflict resolution between scopes: When global says "prefer tabs" but project says "use spaces," the more specific scope wins. We resolve conflicts by scope specificity: session > branch > project > global. Log the override so the user can review decisions.

Architecture deep-dive on memory scoping and compaction: https://blog.kinthai.ai/why-character-ai-forgets-you-persistent-memory-architecture

This is a critical feature. Global-only memory creates real problems at scale — we saw this firsthand running 31 agents across multiple projects on a shared gateway.

The contamination problem is worse than it looks: It's not just "project A's conventions leak into project B." In a multi-agent setup, Agent A's memory about a failed approach in Project X can cause Agent B to avoid a perfectly valid approach in Project Y. The agents develop learned helplessness from memories that don't apply to their current context.

Our scoping model (four levels, similar to what you're proposing):

1. Global: Platform-wide facts (model capabilities, API rate limits, common patterns)
2. Namespace: Organization/team-level conventions and constraints
3. Project: Repository-specific architecture decisions, file structure, coding patterns
4. Session: Ephemeral working state that shouldn't persist

Key design decisions:

• Resolution order: Session > Project > Namespace > Global (most specific wins)
• Explicit override markers: A project memory can explicitly override a global memory (e.g., "this repo uses tabs, not the org-wide spaces convention")
• Memory isolation at delegation: When an agent in Project A delegates to a helper, the helper inherits only Global + the parent's session context — never the parent's project memories. This prevents the contamination you described.

Per-thread / no-carryover mode: We implement this as a "session-only" scope where memories are written to an ephemeral store that's garbage-collected when the session ends. Useful for exploratory tasks where you don't want experimental approaches polluting the persistent store.

The hybrid mode gotcha: When project and global memories conflict, you need a deterministic resolution strategy. We use importance scoring with scope weighting — project memories get a 2x importance multiplier over global memories, so they naturally win in retrieval ranking.

More on the memory architecture (including the importance scoring, time decay, and compaction that makes scoped memory manageable): https://blog.kinthai.ai/why-character-ai-forgets-you-persistent-memory-architecture

Multi-tenant isolation patterns that prevent cross-project contamination at the infrastructure level: https://blog.kinthai.ai/openclaw-multi-tenancy-why-vm-per-user-doesnt-scale

Scope control is the right thing to ask for, but I'd push on the framing a little. The cross-project contamination you're describing isn't really caused by memory being global. It's caused by not being able to tell, later, where a given memory came from and whether you ever actually meant for it to stick. Scope boundaries help, but on their own they just move the contamination around instead of removing it.

The case that breaks pure scoping is the hybrid one you mention. Once project memory and global memory both feed retrieval, "project takes priority" sounds clean until two entries genuinely conflict, or until something that started as a one-off in one repo quietly gets treated as a general preference. At that point what you want isn't a bigger precedence table, it's knowing which entries you confirmed versus which ones got written automatically, so the confirmed ones can win regardless of scope.

The promote/move-between-scopes controls have the same issue. Moving a memory from project to global is exactly the moment it's most likely to be wrong, so that's the moment that benefits most from a deliberate confirmation step rather than a silent reclassification.

We've spent a while building memory that's split into global and project scopes, and the scoping itself turned out to be the straightforward part. The thing that actually made retrieval safer across repos was attaching provenance to each entry and keeping a human in the loop before anything became a durable, cross-project fact. I'd treat namespacing as the floor here, not the feature.

A concrete workflow where project/repository-scoped memory would be especially valuable:

I work with many independent, long-lived repositories and intentionally create a new Codex thread for every development task. This keeps tasks focused and avoids relying on increasingly long thread context.

The downside is that every new thread has to rebuild the same repository context: architecture, CI/CD structure, build and test commands, conventions, prior design decisions, terminology, and known limitations.

Global memory is not suitable for this because these facts belong to the repository, not to the user, and must not leak into unrelated repositories.

The useful hierarchy would be:

Global user preferences → Repository/workspace memory → Task thread

Important controls would include inspect/edit/delete, provenance for each entry, explicit confirmation before promoting repository knowledge to global scope, and protection for secrets and ignored files.

This would eliminate the current trade-off between one oversized thread that retains repository knowledge and clean task-specific threads that repeatedly rebuild it.

A concrete current workaround exists for people who need repository isolation before a native Codex scope UI: GoodMemory v0.7.2.

npm install -g goodmemory@0.7.2
goodmemory setup --host codex --activation-mode workspace_opt_in --writeback off

cd /path/to/repo-a
goodmemory enable codex --workspace-root "$PWD" --workspace-id repo-a --writeback observe
goodmemory status codex --workspace-root "$PWD"

Repeat enable inside each selected repository. Different workspace IDs isolate repository memory; intentionally reusing an ID allows selected worktrees to share that scope. SQLite is the local default. The installed Codex path provides workspace-scoped recall plus read-only MCP inspection, while writeback remains opt-in and records can be inspected, revised, exported, or forgotten.

This is a parallel local memory layer, not a change to Codex built-in memory or thread behavior. Disclosure: I maintain GoodMemory. The commands above were checked against the published GoodMemory 0.7.2 CLI; I am not claiming that release gates prove improved coding outcomes or independent adoption.

Memory has become a necessary feature now that newer models like 5.6 are ignoring AGENTS.md and other requirements docs. Memory fills that gap and really helps (usually just a reminder that the requirement exists). But the contamination is completely breaking the memory feature for me.

One example is my React-based project uses toast popups for validating and error notifications, and my Blazor-based application uses in-line for validation and modals for errors. These are clearly differentiated in the AGENTS.md for each project, but memories are overriding and keep aligning to one project or the other contaminating the other project.

Every time I say it did something wrong, it creates a memory that "fixes" it for one project and completely breaks it for every other project.

Concrete compaction failure this project-scoped memory design should solve

I hit a real continuity failure in a long-running Codex infrastructure session that makes this request more than a cross-project-isolation concern.

Earlier in the thread, Codex had successfully used SSH access to a private host and had the relevant target, user, authentication context, completed steps, and current work in its active context. After context compaction, Codex responded:

“Please resend the SSH password or enable key access for root@<private-host>. I’ll use it only through hidden SSH prompts and will not store or echo it.”

The raw password itself should not become durable project memory. Passwords, tokens, private keys, and other secrets should remain outside normal memory artifacts. However, compaction also discarded the surrounding operational state:

• which host was being managed;
• which SSH user and port were in use;
• which authentication method had already worked;
• that access had already been established in the current thread;
• what changes had already been completed;
• what troubleshooting paths had failed;
• the current task and next action.

That forced the user to re-supply access and partially reconstruct state that Codex had already learned and used. This is exactly where project-scoped operational memory plus secure thread-scoped secret continuity would help.

What the current source already provides

The current repository appears to contain most of the architectural primitives needed:

1. A native memory pipeline

• Feature::MemoryTool is described as startup memory extraction and file-backed memory consolidation in codex-rs/features/src/lib.rs.
• codex-rs/memories/README.md documents a two-phase pipeline:
• Phase 1 extracts structured memory from eligible prior rollouts into state-backed records.
• Phase 2 consolidates those records into ~/.codex/memories, including MEMORY.md, memory_summary.md, and rollout summaries.
• The state migrations already include memory-related persistence, including codex-rs/state/migrations/0006_memories.sql.

1. A memory read/injection path

• codex-rs/ext/memories/src/extension.rs contributes memory context at thread startup.
• codex-rs/ext/memories/src/prompts.rs reads ~/.codex/memories/memory_summary.md and renders it into developer instructions.
• codex-rs/ext/memories/templates/memories/read_path.md instructs Codex to search MEMORY.md, skills, and rollout summaries when prior context may help.

1. Persistent Project objects

• codex-rs/thread-store/src/projects.rs defines stored projects with an ID, name, roots, metadata, and thread associations.
• The app-server protocol accepts an optional projectId when a thread starts.
• The state runtime already persists project/thread associations.

1. Compaction lifecycle seams

• PreCompact and PostCompact are first-class hook event names in codex-rs/protocol/src/protocol.rs.
• codex-rs/core/src/compact.rs invokes pre-compaction hooks, performs compaction, replaces detailed history with retained user messages plus a summary, and then invokes post-compaction hooks.

These pieces suggest that Codex does not need a second independent storage subsystem. The missing capability is wiring the existing Project, memory, and compaction primitives together for synchronous continuity of the active project.

Why the current memory pipeline does not prevent this failure

The existing pipeline is useful, but it solves a different problem:

• It is started when a root session begins.
• It runs asynchronously in the background.
• Phase 1 selects recent prior rollouts that are old/idle enough to process.
• Phase 2 later consolidates selected outputs into global filesystem artifacts.

That means it is not currently a guaranteed, synchronous checkpoint of the live thread immediately before compaction.

The current read path also appears globally rooted in CODEX_HOME:

MemoriesExtensionConfig
  -> codex_home
  -> ~/.codex/memories/memory_summary.md

MemoriesExtensionConfig currently carries enabled, dedicated_tools, and codex_home, but not the active project_id, project roots, or current working directory. build_memory_tool_developer_instructions(...) similarly receives only codex_home.

Therefore, the current system can have memory and still miss the specific operational state needed after a compaction boundary.

Proposed model: four distinct state layers

The implementation should separate four kinds of state rather than treating all of them as one memory blob.

| Layer | Scope | Examples | Persistence |
|---|---|---|---|
| Global memory | User/Codex installation | preferred command style, general conventions, communication preferences | Durable across projects |
| Project memory | Codex Project / repo roots | architecture decisions, environment facts, runbooks, known failures, durable project constraints | Durable across threads in the same project |
| Active operational checkpoint | Project + thread | current target, completed steps, work in progress, next action, active incident state | Survives compaction/resume; expires or closes when work completes |
| Secret lease/reference | Thread + approved tool boundary | SSH password handle, temporary token handle, sudo credential handle | Never stored as ordinary memory; short-lived and tightly scoped |

The critical rule should be:

memory remembers what the secret is for;
secure runtime state holds the secret itself.

Proposed compaction lifecycle

A native lifecycle could be:

long-running project thread
        |
        v
context approaches compaction boundary
        |
        v
safe conversational/tool boundary
        |
        v
PreCompact project checkpoint
  - identify active project and thread
  - capture durable facts and current work
  - bind claims to observable history/tool receipts
  - redact or replace secret material with opaque references
  - persist checkpoint atomically
        |
        v
normal Codex compaction
  - retain summary and selected messages
        |
        v
PostCompact restoration
  - inject bounded active checkpoint
  - inject relevant project memory
  - optionally overlay global memory
  - continue from the recorded next action

PreCompact should preserve at least

• active project_id and matching project roots;
• thread ID and compaction window/checkpoint ID;
• current task and desired outcome;
• confirmed environment/host facts;
• completed actions with evidence references;
• failed or rejected approaches and why they were rejected;
• unresolved blockers;
• next intended action;
• files/artifacts created or modified;
• user-confirmed constraints and decisions;
• authentication method and reference, never the raw secret;
• source/provenance and staleness metadata.

PostCompact should restore

• the active operational checkpoint first;
• only project memory relevant to the active project/task;
• a small global overlay for genuinely cross-project preferences;
• no unrelated project memory;
• no raw credentials.

The active checkpoint should be host-owned structured state, not only a free-form model summary. A model can propose candidate fields, but the runtime should attach canonical project/thread IDs, tool call IDs, timestamps, file paths, and other evidence it can verify directly.

Example checkpoint for the reported SSH workflow

{
  "schema_version": "project-checkpoint/v0.1",
  "checkpoint_id": "<uuid>",
  "project_id": "<codex-project-id>",
  "thread_id": "<thread-id>",
  "status": "active",
  "task": "Configure the target host and validate the deployment",
  "environment": {
    "target": "<private-host>",
    "protocol": "ssh",
    "user": "root",
    "port": 22
  },
  "authentication": {
    "method": "password",
    "credential_ref": "secret://thread/<thread-id>/ssh/root@<private-host>",
    "secret_persisted_in_memory": false
  },
  "completed": [
    {
      "statement": "SSH access was established successfully",
      "source_ref": "tool-call:<id>",
      "status": "confirmed"
    },
    {
      "statement": "Configuration step A completed",
      "source_ref": "tool-call:<id>",
      "status": "confirmed"
    }
  ],
  "failed_attempts": [
    {
      "statement": "Approach B failed because of <observable error>",
      "source_ref": "tool-call:<id>",
      "status": "confirmed"
    }
  ],
  "next_action": "Run validation command C",
  "validity": {
    "git_sha": "<sha-or-null>",
    "created_at": "<timestamp>",
    "expires_at": "<optional-timestamp>"
  }
}

After compaction, Codex should be able to recover:

Target: root@<private-host>:22
Authentication method: password via an existing thread-scoped credential reference
Access was previously confirmed
Completed: A
Rejected/failed: B, because ...
Next action: C

It should not need the user to reconstruct the entire workflow.

Secure secret continuity

Project memory alone should not attempt to remember passwords. The reported failure also exposes the need for a separate secure runtime mechanism.

A safe design could provide optional thread-scoped secret slots or leases:

• A secret entered through an approved hidden prompt is stored in memory protected by the OS keyring, an encrypted local backend, or a process-isolated in-memory store.
• The model receives only an opaque identifier such as secret://thread/....
• Only the approved tool adapter can resolve the handle for the specific host/user/action.
• The plaintext secret is never injected into model context, compaction summaries, MEMORY.md, rollout summaries, logs, analytics, hook payloads, or child-agent context.
• The lease is bound to:
• thread ID;
• project ID;
• target host/user or another explicit resource identity;
• approved tool class;
• TTL and maximum uses.
• It is destroyed on thread termination, explicit user revocation, project change, TTL expiry, or policy change.
• It cannot be promoted to global/project memory.
• If no secure secret backend is enabled, Codex should preserve the non-secret access metadata and request the credential again after compaction. That is still materially better than losing all operational state.

SSH keys and ssh-agent remain the preferred path, but password-based infrastructure workflows still exist and should not force plaintext secrets into the context window as the only continuity mechanism.

Project routing and retrieval

Project memory should be keyed primarily by the existing Codex project_id, not solely by a raw cwd string.

Recommended routing order:

1. Explicit thread project_id.
2. Existing Project whose configured roots contain the active workspace root.
3. Normalized Git repository root as a provisional project key.
4. Thread-only fallback when no stable project identity exists.

This handles multiple worktrees and multi-root projects better than hashing the current directory alone.

A possible filesystem layout, building on the current memory root, would be:

~/.codex/memories/
  global/
    memory_summary.md
    MEMORY.md
  projects/
    <project-id>/
      memory_summary.md
      MEMORY.md
      rollout_summaries/
      skills/
  active_checkpoints/
    <project-id>/
      <thread-id>.json

The exact storage can remain an implementation choice. Active checkpoints may fit better in the existing state database for atomicity and lifecycle management, while consolidated project memory can remain file-backed and inspectable.

Retrieval precedence should be:

active thread checkpoint
  > project memory
  > global memory

More specific state should override less specific state, but the system should preserve conflicts and provenance rather than silently rewriting history.

Memory item quality and staleness

Each durable item should distinguish at least:

• user-confirmed constraint;
• accepted decision;
• direct observation;
• completed action;
• unfinished work;
• rejected approach;
• unverified hypothesis;
• stale or superseded information.

Useful metadata includes:

• project_id and optional affected roots/files/symbols;
• source thread/turn/tool call;
• valid_at_sha when a Git checkout is involved;
• created/updated timestamps;
• status and confidence derived from evidence, not model confidence language;
• supersedes/superseded-by relationships;
• expiry or staleness checks;
• sensitivity classification;
• whether user approval is required before treating the item as authoritative.

A remembered hypothesis must not later be treated as a confirmed fact. A previous successful SSH connection must not imply that the host is still reachable indefinitely. A project decision that has been superseded should remain auditable but should not control current execution.

User controls

This should be inspectable and reversible from both CLI and app surfaces.

Potential controls:

codex memory list --scope project
codex memory show <id>
codex memory forget <id>
codex memory clear --project <project-id>
codex memory promote <id> --to global
codex memory move <id> --to project <project-id>
codex memory checkpoint show --thread <thread-id>
codex secret leases
codex secret revoke <lease-id>

App UI could expose a Project > Memory view with:

• durable project facts/decisions;
• active checkpoints;
• source and last-verified information;
• edit, forget, supersede, or promote actions;
• clear indication that secret values are not part of memory;
• enabled/disabled state and retention policy.

Suggested implementation seams in the current source

This proposal appears alignable with existing code rather than requiring a parallel architecture:

1. Project-aware memory extension configuration

• Extend MemoriesExtensionConfig in codex-rs/ext/memories/src/extension.rs with active project_id, project roots, and/or normalized workspace identity.
• Pass that scope to build_memory_tool_developer_instructions(...).
• Render global plus matching project summary rather than one undifferentiated global summary.

1. Project-partitioned consolidation

• Phase 1 already has thread/state metadata available.
• Partition Phase 2 inputs by project ID/root and consolidate project artifacts separately, with a small explicit global partition.

1. Native pre-compaction checkpoint contributor

• Invoke an internal checkpoint operation before run_compact_task_inner_impl(...) replaces history.
• Use the existing PreCompact lifecycle and canonical session/tool history.
• Do not rely solely on a third-party shell hook for a first-party safety/continuity guarantee.

1. Bounded post-compaction injection

• After history replacement, inject a compact active checkpoint and relevant project summary through the same structured prompt-fragment/context system used by extensions.

1. State DB lifecycle

• Store active checkpoints keyed by project/thread/compaction window, with atomic revisioning and cleanup.
• Reuse the existing project/thread association instead of inferring project identity repeatedly.

1. Secret reference boundary

• Add a separate secret-handle service only if OpenAI wants same-thread secret reuse.
• Keep it outside the memory pipeline and enforce non-exportability into model-visible or persisted memory surfaces.

Acceptance criteria

A minimal implementation should satisfy all of the following:

1. A long-running project thread can compact and continue with its current task, completed steps, failed approaches, environment target, and next action intact.
2. The checkpoint is created before detailed history is replaced and is bound to the correct project and thread.
3. A new thread in the same Project can retrieve durable project memory but does not inherit an unrelated thread’s temporary secret lease.
4. A thread in a different Project receives none of the first project’s operational memory unless an item was explicitly promoted to global scope.
5. Raw passwords, tokens, SSH keys, and similar secrets never appear in memory files, memory DB rows, compaction summaries, logs, analytics, hook payloads, or child-agent prompts.
6. When secure secret leases are enabled, the same live thread can continue using an already approved credential after compaction without revealing the plaintext to the model.
7. When secure secret leases are not enabled or have expired, Codex retains all non-secret operational state and asks only for the missing credential.
8. Project memory and active checkpoints are user-inspectable, editable/forgettable, and clearable by project.
9. Memory items preserve status/provenance so hypotheses, completed actions, user constraints, and superseded decisions are not conflated.
10. Worktrees and multi-root projects route to the intended Project identity.
11. Retrieval remains bounded and injects only relevant project/global summaries rather than the entire memory corpus.
12. If checkpoint creation fails, compaction does not silently imply continuity; the user receives an explicit warning while normal compaction can proceed.
13. Disabled memory mode adds no project checkpoint persistence or prompt injection.
14. Existing sandbox, approval, hook, enterprise policy, and data-retention controls remain authoritative.

Relationship to existing issues

• #24810 proposes structured context preservation around session boundaries and compaction.
• This issue (#18343) proposes explicit global/project/thread memory scope.

The concrete gap is the intersection of those two requests:

Project-scoped memory must participate synchronously in the compaction lifecycle, while sensitive credentials use a separate secure thread-scoped reference/lease mechanism.

This is not a request to store SSH passwords in MEMORY.md. It is a request for Codex to stop using the context window as the only place where active project state and temporary access continuity can exist.

The desired user-visible result is straightforward:

Compaction completed.
Resuming project state:
- target: root@<private-host>:22
- authentication: existing thread-scoped reference, or credential required if unavailable
- access previously confirmed
- completed: A
- failed/rejected: B because ...
- next action: C

That would directly prevent the workflow interruption described above while preserving a strong secret-handling boundary.

@en4ble1337 this incident usefully separates three state classes that should not be collapsed into one memory tier:

1. durable project facts: architecture, runbooks, completed decisions, and known failed approaches;
2. an active operational checkpoint: current target, completed steps, current blocker, and next action;
3. a secret lease/reference: the credential value remains outside ordinary memory and is usable only through an approved runtime boundary.

GoodMemory 0.7.5 can cover the first class and parts of the second when a host explicitly captures selected, redacted state. Its installed path keeps raw transcripts out of durable memory, scopes records to a workspace, and exposes audit/correction/deletion. It does not currently provide a Codex-native synchronous PreCompact checkpoint or a secure credential-handle service, so I would not claim it fully solves the failure you described.

A useful native acceptance test would be:

• establish access and complete several observable steps;
• force compaction with the live task still open;
• verify that host/user/port, completed work, failed paths, blocker, and next action resume without re-entry;
• verify that the password/token value is absent from memory records, summaries, indexes, logs, and exported artifacts;
• revoke the secret lease independently from deleting the non-secret operational checkpoint;
• verify that current code, tool receipts, tests, and the latest user instruction override stale checkpoint data.

That test distinguishes continuity from credential persistence and avoids using ordinary project memory as a secret store. Disclosure: I maintain GoodMemory; this is a capability-boundary note, not evidence that the current release fixes Codex native compaction.