Body
Summary
On Windows Desktop, global AGENTS.md behavior appears inconsistent across new threads.
I am seeing two related symptoms:
The app injects AGENTS.md content into the very first user message as an # AGENTS.md instructions for ... block with full .
In some sessions, the agent then skips the actual disk read of the global AGENTS.md and behaves as if the injected text is equivalent to reading the file.
At the same time, the desktop logs show fs/watch failures for AGENTS.md and MEMORY.md with:
Invalid request: AbsolutePathBuf deserialized without a base path
I do not know yet whether these are the same root cause, but they look closely related.
Why this matters
If a global AGENTS.md explicitly says “read this file first”, injected startup instructions should not be treated as a replacement for a real disk read.
Right now, startup behavior can diverge between sessions even when the initial user prompt is the same.
Environment
Codex Desktop on Windows
cli_version: 0.122.0-alpha.13
App package observed locally:
OpenAI.Codex_26.417.5275.0_x64__2p2nqsd0c76g0
Memories were disabled during comparison:
features.memories = false
memories.generate_memories = false
memories.use_memories = false
Repro pattern
This is not yet a single 100% minimal repro, but it is reproducible as a session pattern.
Configure a global ~/.codex/AGENTS.md that explicitly requires reading itself first.
Use Codex Desktop on Windows.
Start a new thread in a project that also has local AGENTS.md and INDEX.md.
Use the same first user prompt in two fresh threads, for example:
load minimal context
Inspect the rollout JSONL and the first tool calls.
Observed behavior
In both sessions:
the first user-role block already contains:
AGENTS.md instructions for ...
full
But the follow-up behavior differs:
In one session, the agent performs a real disk read of the global ~/.codex/AGENTS.md immediately.
In another session, it does not read the global AGENTS.md from disk until the user explicitly challenges it.
In the second case, the agent effectively treats the injected startup instructions as sufficient.
Expected behavior
If global AGENTS.md says it must be read first, Codex should perform the actual file read from disk consistently.
Injected startup instructions should not silently count as an equivalent replacement for that disk read.
fs/watch for AGENTS.md should not fail on Windows.
Actual behavior
Startup prompt already includes injected AGENTS instructions.
Real disk-read of global AGENTS.md is inconsistent across otherwise similar sessions.
Desktop logs show watcher failures for the same class of files.
Relevant log signal
Desktop log repeatedly shows:
method=fs/watch
Invalid request: AbsolutePathBuf deserialized without a base path
Failed to watch review file source tab
Affected files include:
global AGENTS.md
MEMORY.md
Additional observations
This does not appear to be caused by Memories, because the compared sessions were already running with memories disabled.
The packaged runtime also appears to contain startup/prompt-hook machinery such as:
UserMessageHookPrompt
PromptHookOutputEntry
SessionStart
SystemProject
turn_context
That makes me suspect this is in the desktop/runtime startup pipeline rather than being purely model behavior.
Potentially related issues
These may be related, but I cannot confirm same root cause:
#16815
#15421
#8547
#17496
What would help
I would mainly want clarification on:
Is injected AGENTS.md startup content intended to count as “file read” semantics?
Is the fs/watch AbsolutePathBuf error a known Windows Desktop bug for instruction/source files?
Is there a supported way to force consistent disk-read of global AGENTS.md before skill routing starts?
Attachments available
I have local evidence for:
two rollout traces showing the injected startup block and divergent disk-read behavior
desktop logs showing fs/watch failures
config showing memories disabled
I can provide sanitized excerpts if needed.
Body
Summary
On Windows Desktop, global AGENTS.md behavior appears inconsistent across new threads.
I am seeing two related symptoms:
The app injects AGENTS.md content into the very first user message as an # AGENTS.md instructions for ... block with full .
In some sessions, the agent then skips the actual disk read of the global AGENTS.md and behaves as if the injected text is equivalent to reading the file.
At the same time, the desktop logs show fs/watch failures for AGENTS.md and MEMORY.md with:
Invalid request: AbsolutePathBuf deserialized without a base path
I do not know yet whether these are the same root cause, but they look closely related.
Why this matters
If a global AGENTS.md explicitly says “read this file first”, injected startup instructions should not be treated as a replacement for a real disk read.
Right now, startup behavior can diverge between sessions even when the initial user prompt is the same.
Environment
Codex Desktop on Windows
cli_version: 0.122.0-alpha.13
App package observed locally:
OpenAI.Codex_26.417.5275.0_x64__2p2nqsd0c76g0
Memories were disabled during comparison:
features.memories = false
memories.generate_memories = false
memories.use_memories = false
Repro pattern
This is not yet a single 100% minimal repro, but it is reproducible as a session pattern.
Configure a global ~/.codex/AGENTS.md that explicitly requires reading itself first.
Use Codex Desktop on Windows.
Start a new thread in a project that also has local AGENTS.md and INDEX.md.
Use the same first user prompt in two fresh threads, for example:
load minimal context
Inspect the rollout JSONL and the first tool calls.
Observed behavior
In both sessions:
the first user-role block already contains:
AGENTS.md instructions for ...
full
But the follow-up behavior differs:
In one session, the agent performs a real disk read of the global ~/.codex/AGENTS.md immediately.
In another session, it does not read the global AGENTS.md from disk until the user explicitly challenges it.
In the second case, the agent effectively treats the injected startup instructions as sufficient.
Expected behavior
If global AGENTS.md says it must be read first, Codex should perform the actual file read from disk consistently.
Injected startup instructions should not silently count as an equivalent replacement for that disk read.
fs/watch for AGENTS.md should not fail on Windows.
Actual behavior
Startup prompt already includes injected AGENTS instructions.
Real disk-read of global AGENTS.md is inconsistent across otherwise similar sessions.
Desktop logs show watcher failures for the same class of files.
Relevant log signal
Desktop log repeatedly shows:
method=fs/watch
Invalid request: AbsolutePathBuf deserialized without a base path
Failed to watch review file source tab
Affected files include:
global AGENTS.md
MEMORY.md
Additional observations
This does not appear to be caused by Memories, because the compared sessions were already running with memories disabled.
The packaged runtime also appears to contain startup/prompt-hook machinery such as:
UserMessageHookPrompt
PromptHookOutputEntry
SessionStart
SystemProject
turn_context
That makes me suspect this is in the desktop/runtime startup pipeline rather than being purely model behavior.
Potentially related issues
These may be related, but I cannot confirm same root cause:
#16815
#15421
#8547
#17496
What would help
I would mainly want clarification on:
Is injected AGENTS.md startup content intended to count as “file read” semantics?
Is the fs/watch AbsolutePathBuf error a known Windows Desktop bug for instruction/source files?
Is there a supported way to force consistent disk-read of global AGENTS.md before skill routing starts?
Attachments available
I have local evidence for:
two rollout traces showing the injected startup block and divergent disk-read behavior
desktop logs showing fs/watch failures
config showing memories disabled
I can provide sanitized excerpts if needed.