It seems that when I start a new codec session on my iOS device or if I'm sending the first prompt from a session started on my machine, there is project memory that comes into the session that's unrelated to my prompt. I'll paste below a bug report from Codex of what it thinks happened.
Here’s a cleaner bug-ticket version:
Title: Assistant leaks preloaded project memory into narrow tool-action requests
Issue:
When broad project memory is injected into a Codex session, the assistant may treat that memory as active conversational context instead of routing-only background. In this case, a narrow request to change the chat title for a Demand Dashboard update led to unrelated project context being blended into the conversation.
Expected Behavior:
For narrow requests, the assistant should perform only the requested action and stop. Preloaded memory should only help route the task or decide what to inspect later. It should not appear in the user-facing response unless the user explicitly asks for prior context or the assistant verifies it during the current turn.
Actual Behavior:
The assistant completed the title-change action, then continued with extra synthesis and referenced unrelated project context, creating confusion about whether Slack, Outlook, Obsidian, or prior project memory had been consulted.
Impact:
This reduces trust because the assistant appears to be using hidden or stale context without permission. It is especially problematic for users working across multiple projects where old memory can easily contaminate the current task.
Likely Root Cause:
The wrapper injects broad memory/context, but the instruction boundary does not strongly separate:
- routing context
- verified current context
- user-facing response content
Suggested Fix:
Add a global guardrail:
Preloaded project memory is for routing and lookup decisions only. Do not mention or rely on memory-derived project facts in user-facing responses unless the user explicitly asks for prior context, or you have verified the fact in the current turn. For narrow tool-action requests, perform only the requested action and do not synthesize from memory.
Acceptance Criteria:
- Narrow tool-action requests produce only the requested action/result.
- Memory-derived facts are not surfaced unless explicitly requested or verified in-turn.
- Cross-project context remains quarantined unless directly necessary.
- The assistant clearly distinguishes user-provided facts, live-retrieved facts, and memory-derived facts.
It seems that when I start a new codec session on my iOS device or if I'm sending the first prompt from a session started on my machine, there is project memory that comes into the session that's unrelated to my prompt. I'll paste below a bug report from Codex of what it thinks happened.
Here’s a cleaner bug-ticket version:
Title: Assistant leaks preloaded project memory into narrow tool-action requests
Issue:
When broad project memory is injected into a Codex session, the assistant may treat that memory as active conversational context instead of routing-only background. In this case, a narrow request to change the chat title for a Demand Dashboard update led to unrelated project context being blended into the conversation.
Expected Behavior:
For narrow requests, the assistant should perform only the requested action and stop. Preloaded memory should only help route the task or decide what to inspect later. It should not appear in the user-facing response unless the user explicitly asks for prior context or the assistant verifies it during the current turn.
Actual Behavior:
The assistant completed the title-change action, then continued with extra synthesis and referenced unrelated project context, creating confusion about whether Slack, Outlook, Obsidian, or prior project memory had been consulted.
Impact:
This reduces trust because the assistant appears to be using hidden or stale context without permission. It is especially problematic for users working across multiple projects where old memory can easily contaminate the current task.
Likely Root Cause:
The wrapper injects broad memory/context, but the instruction boundary does not strongly separate:
Suggested Fix:
Add a global guardrail:
Acceptance Criteria: