Reproducible hallucinations: a tool-surface change makes Codex GPT-5.5 xhigh fabricate tool-use attempts

What version of the IDE extension are you using?

26.616.32156 / 26.616.30709 / 26.609.30741

What subscription do you have?

Plus

Which IDE are you using?

VS Code

What platform is your computer?

Microsoft Windows NT 10.0.26100.0 x64

What issue are you seeing?

When an existing Codex thread (GPT-5.5 xhigh) is resumed after its available tool surface changes, it can execute fabricated shell commands instead of using the available tool-discovery mechanism.

The failure mode is this:

1. Codex has a tool available and uses it.
2. After the call finishes, the previous way of invoking that tool is no longer available.
3. When asked to probe that tool again, Codex fabricates the requested probe by producing unrelated shell activity that resembles real work, instead of finding and calling the tool.

The concrete reproducer was the ask-human MCP, but the mechanics suggest that this is not specific to that tool. I did not have much time to search for another reproducer while chasing my third Codex issue today.

What steps can reproduce the bug?

1. Use VS Code Codex extension 26.616.32156 (which, as described in #29122, forces MCP calls through code-mode exec, that changes the tool surface in the way we want for this repro). Start a new Codex thread with GPT-5.5 / xhigh.
2. Ask Codex to invoke an existing configured MCP tool. Check the session rollout file to confirm that it wrapped the MCP call in code-mode exec.
3. Ask it to do so again just to confirm / reinforce the tool's availability.
4. Switch the extension to 26.609.30741 (which doesn't use code-mode exec) and reload the extensions.
5. Resume the same Codex thread.
6. Now ask Codex to invoke the same MCP tool again without mentioning any potential changes to the tool surface.
7. Observe what Codex does: it may execute fabricated or meaningless shell commands, imitating an attempt to use the tool, before eventually using tool_search and invoking the MCP tool properly.

The exact prompts used in both reproductions were:

ask-human tool probe
Call it, wait for my answer, then tell if that looked on your side as a single uninterrupted call or if you received any intermediate updates where you could terminate it or not

After that succeeds, run it one more time without changing the tool surface:

let's try again, now, if you have that option, terminate as soon as you can.

After that succeeds, switch from the extension version that uses code-mode exec to the direct-MCP version 26.609.30741, so the tool surface changes and the code-mode exec is no longer available:

okay we were on 26.616.30709

Now I switched to 26.609.30741

let's try again and see if it still yields each 10 seconds

This reproduced in 2/2 attempts.

1st reproduced run

Instead of using tool_search, Codex executed this nonsense:

@'
print('Cannot directly call ask_human from shell; using tool execution path next.')
'@ | python -

and then:

Get-Command nonexistent-ask-human-probe -ErrorAction SilentlyContinue

The first command only printed a model-authored message. The second command was also fabricated and probed nothing. It is safe to say that it was a pure hallucination in this context.

Only afterward, Codex used the correct path:

tool_search("ask_human ask human MCP tool")
-> mcp__ask_human
-> direct MCP tool call

2nd reproduced run

Codex also fabricated shell command:

Write-Output 'probe'

It then used tool_search and invoked the MCP tool normally.

The exact fabricated command varied, but the behavior reproduced in both attempts.

What is the expected behavior?

Codex should not fabricate shell commands or output to imitate the requested probe when a previously used tool is no longer exposed. It should use tool_search.

Additional information

• The exact extension versions mentioned above are not important; they were just a concrete way to reproduce the tool-surface change that triggered the model-inference hallucination.
• Both reproductions used GPT-5.5 / xhigh.
• The fabricated commands were harmless in this case, but that is clearly a model inference quality problem.