Bug Report: Screen reader tool calls being blocked by Codex guardrail
`Steps to Reproduce`
- need a screen reader sometimes
- build a voice inference service MCP because Codex didn't have hooks™ yet
- use that via global
AGENTS.md guidance
- notice new Codex hooks™
- notice the tool layer suddenly ignoring prior items in the agent turn, and blocking TTS tool calls for (paraphrasing) "stating ops that weren't performed", when those exact ops are in recent scrollback, within the same agent turn
- debate whether to use hooks now instead, or cave and build a whole frontend at this point
`Expected Result`
I would expect that, especially on such a short, straightforward agent turn prompted by clear direction, that the tool layer would be scanning items properly. Especially before blocking a call to a screen reader/speech generator with a simple summary of what was, in fact, completed.
`Actual Result`
The tool layer seemingly scanned three items calling to my screen reader:
list profiles, check status, and generate speech w/ the pending contents of the final response item.
It failed to scan the git ops items immediately preceding the aforementioned.
It blocked the speech call on error describing a lack of evidence in the turn for claimed (and performed) git ops.
Unlike prior blocks, it didn't present as an approval, it blocked the screen reader call silently. Worst failure mode for this.
`Environment`
macOS 26.4, iTerm2, codex-cli v0.118.0 via brew Cask, SpeakSwiftlyServer v2.0.4 via MCP (HTTP)
flat trail
elfin dagger
