Consider Introducing Read–Write Locks to Enhance Concurrent Work
Resolved 💬 6 comments Opened Feb 13, 2026 by katze-646 Closed May 10, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor)
responded on this thread — see the highlighted reply below.
What variant of Codex are you using?
all of them
What feature would you like to see?
Since multiple Codex threads may operate on the same files concurrently, edit conflicts are occurring and hampering productivity. We might consider introducing a read–write lock mechanism—similar to Java’s ReentrantReadWriteLock or Go’s sync.RWMutex—to mitigate the risk of concurrent modification conflicts.
Additional information
_No response_
6 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Have you experienced a real problem related to concurrent file updates, or is this a theoretical concern?
Thank you for your response
I have encountered a real problem.
In one of my projects, I was running two Codex threads simultaneously. When both threads modified the same file, it led to edit conflicts and forced the agent to detect why the file changed and must redo work.
A specific example was when I asked Codex in thread 'A' to add comments globally in the project , while thread 'B' was modifying the code logic in the same file. This resulted in overlapping changes and unnecessary rework.
I understand that this partly stems from how I was using the tool, and that running concurrent modifications on the same file may not be the ideal workflow. However, in some scenarios, parallel tasks touching the same file can be a legitimate need. Introducing an optional file-locking mechanism might help reduce such conflicts and improve the user experience.
currently I' m trying to add special markers at the end of the file and tell agent to check if the marker exist before modifying.
My related use-case (mentioned in https://github.com/openai/codex/issues/12818) is human+agent both working on the same file. I wasn't thinking 'locks' as a solution, but certainly Codex having 'awareness' that someone else has changed, or is changing a file would be useful.
Seems like the crux of the problem is: we don't know what files Codex touched, and that's not easy to work out.
I notice that Codex is pretty good at simply _stating_ what it changed, I wonder if it could report this more formally? It's not definitive of course, but it might get 90% of the way there. For example, the model could call some
report_file_accesstool (local to the harness) and the harness then stores the fact that agent A is reading file X. And if agent B reads the same file the tool can return "careful there buddy, Agent A is working on that file too". Not exactly a lock but it could prevent clashes in a similar way. The harness would then also have a list of files to watch, and if a human or anything else changed one of them, could note this with subsequent prompts ("BTW, you changed this file but it's been modified again since then")This feature request hasn't received enough upvotes, so I'm going to close it.