Codex App: developer_instructions (config.toml) are not attached to threads initiated within the App
Open 💬 9 comments Opened Feb 7, 2026 by miraclebakelaser
💡 Likely answer: A maintainer (miraclebakelaser, contributor)
responded on this thread — see the highlighted reply below.
What version of the Codex App are you using (From “About Codex” dialog)?
260206.1448 (565)
What subscription do you have?
Pro
What issue are you seeing?
The developer_instructions config allows users to inject a custom developer message into conversations. The issue is that the developer_instructions value does not get injected into threads initiated from within Codex App.
How instructions are currently constructed in Codex App threads:
# <instruction block> (source)
<system instructions> (codex)
<permissions instructions> (codex)
<app-context> (codex)
<INSTRUCTIONS> (AGENTS.md)How instructions should be constructed in Codex App threads:
# <instruction block> (source)
<system instructions> (codex)
<permissions instructions> (codex)
<app-context> (codex)
+<developer_instructions> (config.toml)
<INSTRUCTIONS> (AGENTS.md)What steps can reproduce the bug?
- Set custom
developer_instructionsin~/.codex/config.toml. e.g. "Start every thread by saying 'good morning!'" - Initiate a conversation in Codex CLI
- Initiate a conversation in Codex App
- Note the conspicuous lack of a "good morning!" in Codex App
- Review the respective thread JSONLs in
~/.codex/sessions/ - Observe the missing instructions from Codex App-initiated thread
What is the expected behavior?
developer_instructions should apply to threads in Codex CLI and Codex App.
Additional information
_No response_
9 Comments
@miraclebakelaser, could it be that you have appended your developer_instructions statement to the end of the config.toml and it happen to be in some toml section, not on a global level?
P.S. I was having this case :)
@vak had to double check – not in my case!
This is still an issue for me.
@etraut-openai can you label this a bug?
I found a slight workaround for this. There are custom instructions under Settings -> Personalization. This appears to save an AGENTS.md in the ~/.codex directory. However, these are still loaded in as user role messages. Repo AGENTS.md are loaded in as developer role instructions often overruling my custom instructions. I do understand the motivation for that priority, however, I think a better approach is to let the user choose what role they come in as. I want my custom instructions to be developer role instructions and then the repo level AGENTS.md to be user role messages because I may work in a repo that says, do not use worktrees. Well, I want to use worktrees and I shouldn't be overruled by a random repo's AGENTS.md file.
I'm not a big fan of the custom instructions in Codex App settings because 1) it gets injected into non-Codex App (ie CLI) instructions and 2) they are user instructions. I didn't know it was via
~/.codex/AGENTS.md, thanks for the tip.Instruction layering is one of the most important tools we have.
From: Unrolling the Codex agent loop
<img width="961" height="597" alt="Image" src="https://github.com/user-attachments/assets/dfed602d-5500-4036-b622-a2987eccec3f" />
That works great with Copilot, where we can control the behavior of agent, add reviewers, implementers, researchers, and etc. I would happy to have similar in Codex, to be able set my rules and behavior I expect from codex. Not via User messages, but more strong system instructions
This also becomes a provenance problem, not just an instruction problem. If app-initiated threads omit developer_instructions, the session needs to say so explicitly in its effective instruction receipt, otherwise users debug behavior from outputs while assuming the config actually loaded. The safest model for me is: system and app instructions, developer_instructions hash, AGENTS.md hash, then the merged effective contract written into thread metadata up front. We ended up needing that same receipt layer in MartinLoop because hidden instruction drift is brutal to debug once runs get long.
Still an issue. Really annoying. Please fix!