invalid_request_error after any prompt in some conversations #15193

Activity

1. andrew-valon

   added

   bugSomething isn't workingSomething isn't working

   on Mar 19, 2026
2. andrew-valon

   changed the title [-]invalid_request_error[/-] [+]invalid_request_error after any prompt in some conversations[/+] on Mar 19, 2026
3. github-actions

   added

   CLIIssues related to the Codex CLIIssues related to the Codex CLI

   on Mar 19, 2026
4. etraut-openai commented on Mar 19, 2026

   

   etraut-openai

   on Mar 19, 2026

   Contributor

   More actions

   Do you have any experimental features enabled? If so, this is the likely explanation for why you're seeing this.
5. etraut-openai

   added

   agentIssues related to the core agent loopIssues related to the core agent loop

   and removed

   CLIIssues related to the Codex CLIIssues related to the Codex CLI

   on Mar 30, 2026
6. imajes commented on May 28, 2026

   

   imajes

   on May 28, 2026

   More actions

   Do you have any experimental features enabled? If so, this is the likely explanation for why you're seeing this.

   hey @etraut-openai -- which one is causing this to happen?
7. imajes commented on May 28, 2026

   

   imajes

   on May 28, 2026

   Last edited by imajes

   More actions

   a quick update @etraut-openai - here's the problem more concretely specified, with a note about mitigation:

   I found what looks like the same class of failure locally, although in my case the rejected field is input[].namespace rather than input[].name.

   The symptom matches this issue: after a conversation contains the bad historical item, every later prompt in that conversation fails before the model runs because the old item is replayed into the next response.create.

   In my trace DB, the failing websocket request was:

   model:      gpt-5.5
   thread:     019e6cc6-e294-78a3-b84f-3f45a4299d45
   turn:       019e6cdc-0b22-7362-bf90-104e210bacc9
   local time: 2026-05-27 23:33:41
   error:      input[31].namespace does not match ^[a-zA-Z0-9_-]+$
   

   The rejected historical input item was:

   {
     "type": "function_call",
     "name": "search",
     "namespace": "memories/",
     "call_id": "call_apzrz3rZhRuc3FLS9wLwaHyq",
     "arguments": "{\"path\":\"MEMORY.md\",\"queries\":[\"default_permissions permissions.workspace sandbox_mode\"],\"match_mode\":{\"type\":\"all_within_lines\",\"line_count\":6},\"context_lines\":2,\"max_results\":10}"
   }

   The server response was:

   {
     "type": "error",
     "error": {
       "type": "invalid_request_error",
       "message": "[StringParam] [input[31].namespace] [invalid_string] Invalid 'input[31].namespace': string does not match pattern. Expected a string that matches the pattern '^[a-zA-Z0-9_-]+$'."
     },
     "status": 400
   }

   In my local checkout, the immediate source appears to be the memory extension namespace constant:

   // ext/memories/src/lib.rs
   pub(crate) const MEMORY_TOOLS_NAMESPACE: &str = "memories/";

   That value is used to build a Responses API namespace tool spec in ext/memories/src/tools/mod.rs. The trailing slash is invalid under the current API regex. The path is gated by memories.dedicated_tools, which defaults to false, so this is likely an opt-in path, but once one of these calls exists in conversation history, disabling the tool path does not repair the already-contaminated thread.

   This may explain why the original report sees the error “after every prompt in some conversations”: the problem is not necessarily the new prompt, but a prior function_call item being replayed into each new request.

   Suggested fixes:

   1. Validate all outgoing input[] function/tool identifiers client-side before websocket submission and report the offending index locally.
   2. Normalize or reject invalid historical response items during replay, not only when emitting new tool specs.
   3. Add regression coverage that emitted tool names/namespaces match ^[A-Za-z0-9_-]+$.
   4. For the memory extension specifically, change memories/ to an API-valid namespace such as memories.

   The key point is that fixing only future tool emission may not recover existing affected conversations unless replayed history is also normalized or filtered.
8. imajes commented on Jun 20, 2026

   

   imajes

   on Jun 20, 2026

   More actions

   good news! this was fixed in PR #24898. Thanks @jif-oai

   This can almost certainly be closed now, but I do not have those permissions.
9. etraut-openai

   closed this as completedon Aug 3, 2026