Realtime voice sessions do not receive AGENTS.md / Personality instructions that text sessions do
What version of the Codex App are you using (From “About Codex” dialog)?
26.803.10989.0
What subscription do you have?
Max
What platform is your computer?
Microsoft Windows NT 10.0.26200.0 x64
What issue are you seeing?
Summary
On Codex desktop for Windows, instructions from ~/.codex/AGENTS.md (the Personality section) reach text conversations but appear to be absent from realtime voice conversations. Every new voice conversation starts without the assistant's identity or any user context, and only acquires it after the user explicitly tells it to read memory. A new text conversation, in the same install and at the same moment, knows all of it immediately.
Environment
Codex desktop (MSIX), version 26.803.10989.0
Windows 11 Pro 26200
model = "gpt-5.6-sol", model_reasoning_effort = "high"
Persona configured through the app's Personality setting, stored in ~/.codex/AGENTS.md
Steps to reproduce
Put identifying text in the Personality setting, e.g. a line naming the assistant and the user.
Open a new text chat. Ask "who am I and who are you". → answers correctly and immediately.
Open a new voice chat. Ask the same question by voice. → does not know; answers generically until told to consult memory.
Repeat after each new voice conversation. Behaviour is consistent.
What I verified
codex debug prompt-input, run from the voice conversation's own project directory (~/Documents/codex/<date>/realtime-voice-chat), does contain the persona text — the identity strings are present in the rendered prompt. So the instructions are resolved correctly for that working directory; the text path receives them and behaves accordingly, while the voice path behaves as if it never saw them.
Additional observations from the same investigation:
A project-level AGENTS.md placed directly inside the voice conversation folder is also present in codex debug prompt-input, yet does not change voice behaviour either.
An AGENTS.md placed in the parent directory of the voice conversation folders is not inherited (marker string absent from prompt-input). This may be intentional, but it means there is no single location that covers all voice conversations, since each one gets its own project folder.
~/.codex/memories/memory_summary.md never appears in prompt-input at all. Memory seems to be consulted only on demand, which compounds the problem for voice: the assistant has neither instructions nor summary at wake-up.
Expected behaviour
A new realtime voice conversation should start with the same instruction stack as a new text conversation — at minimum the Personality / AGENTS.md content.
Impact
For always-on voice use this is a per-conversation tax. The assistant begins every conversation context-blind, and the only workaround is to spend a turn telling it to read memory. It also defeats the purpose of the Personality setting for anyone whose primary surface is voice.
Related: #35103 (voice mode thread disappears after inactivity timeout) — same area, different symptom.
What steps can reproduce the bug?
Steps to reproduce
- Put identifying text into the Personality setting — something the assistant
could only know from there, e.g. the assistant's name and the user's name.
It is stored in ~/.codex/AGENTS.md.
- Open a new text chat. Ask: "who am I and who are you?"
→ Answers correctly and immediately.
- Open a new voice chat. Ask the same question by voice.
→ Does not know either. Stays generic until explicitly told to read memory.
- Repeat step 3 with any further new voice conversation. Same result every time.
Same machine, same settings, same minute — only the surface differs.
Verification that the instructions do reach that conversation
Each voice conversation gets its own project folder under
`~/Documents/codex/<date>/realtime-voice-chat
What is the expected behavior?
A new realtime voice conversation should start with the same instruction stack
as a new text conversation — at minimum the Personality / AGENTS.md content.
Concretely, in the reproduction above, step 3 should behave like step 2: asked
"who am I and who are you?", the assistant answers from the Personality setting
immediately, without being told to consult memory first.
The Personality setting is presented as a global, surface-independent way to
tell Codex who it is and who it is working with. Today it silently applies to
one surface and not the other, with no indication in the UI that voice is
excluded.
If the exclusion is deliberate — for example because the realtime voice layer
runs a separate model with its own prompt — then the expected behaviour would be
a supported way to give that layer a small amount of standing context: either a
voice-specific instructions field, or an explicit note in the Personality
settings UI that it does not apply to voice, so users are not left guessing.
Additional information
Some context on why this matters to me: I build voice agents, and now trying to build one on Codex.
For an agent that lives in voice, standing identity has to be true at wake-up.
Having to say "go read your memory" before every conversation costs a round
trip, and in voice a round trip is an audible pause. That is the one thing
currently keeping me from building on Codex — everything else in the stack works
well.
In my own project I ended up loading the session prompt from user files, re-read
on each connection: persona in one file, a short "memory pill" in another. I am
not suggesting that as the design — you know the constraints on the realtime
layer far better than I do. I mention it only because it makes me hopeful the
gap is a small one, since the Personality setting already exists and already
works for text.
One smaller thing, separate from the fix itself: nothing in the UI indicates
that Personality does not apply to voice. A short note in the settings would
have saved me an evening of figuring it out empirically, and might be much
easier to ship than the wiring itself.
3 Comments
I reproduced a closely related failure on Windows app 26.803.81509 (bundled
codex-cli 0.147.0-alpha.6.6) with paired iOS Remote Voice.I first confirmed the source distinction:
core/src/realtime_context.rsexplicitly notes that realtime startup context excludes AGENTS files and memory summaries.experimental_realtime_ws_backend_promptoverrides the realtime conversational-layer prompt, while AGENTS instructions reach the Codex executor only after handoff.Controlled before/after test:
experimental_realtime_ws_backend_promptto the current upstreambackend_prompt.mdplus an explicit rule requiring delegation for ambiguous references including “what I asked,” fully restarted the app, and created a fresh Voice task.So the host-side override affected laptop Voice behavior but did not make the paired iOS surface follow the same mandatory handoff rule. This suggests either paired iOS Remote Voice uses a separate prompt/routing path, or the realtime model is not consistently applying the host prompt to ambiguous contextual requests.
This matters because AGENTS-based personalization and memory orchestration cannot help until Live delegates. Could maintainers clarify whether paired iOS Remote Voice is expected to honor the Windows host's realtime backend prompt/configuration? A supported append-style Voice instruction mechanism (rather than replacing the complete upstream prompt) would also make this substantially safer to configure.
Follow-up/correction after a second fully restarted test: paired iOS Remote Voice does receive the Windows host's
experimental_realtime_ws_backend_promptoverride.I added a temporary diagnostic instruction requiring every spoken response to begin with the exact words “MY TURN,” restarted the Windows app, and initiated Voice from the paired phone. The phone consistently prefixed its replies with “MY TURN.” The new call also reattached to the same existing Codex thread ID rather than creating a new thread; the UI briefly looked like a blank/new conversation while connecting, then hydrated into the existing thread.
This narrows the residual bug: the override reaches paired iOS, but GPT-Live followed the simple output-prefix instruction while ignoring the equally explicit rule that “what I asked” is a mandatory backend/context-resolution trigger. It answered that phrase literally without handoff. More explicit corrections did hand off and could recover the marker from the same thread transcript.
So the issue is inconsistent realtime instruction adherence / handoff selection for ambiguous contextual requests, not failure to deliver the host prompt to paired iOS. AGENTS still cannot repair this before handoff because it is excluded from the realtime startup context.
Adding one point that I think matters beyond making Personality apply to voice.
Voice should have a supported session profile, rather than relying on an experimental prompt override or asking it to read memory at the start of every call. Before a live session begins, I should be able to choose the working style and see exactly which standing context, skills, and connections it will use.
For my workflow, the important next step is letting voice become the front door to a real Codex task: start fresh or deliberately resume a task, keep the same context when moving between voice and text, and use only the skills and local-harness connections I have explicitly approved. That includes a personal knowledge source such as My Brain and an execution layer.
The permission model needs to stay visible and deliberate. I do not want hidden access; I want a clearly configured voice operator that can actually carry work forward.