invalid_request_error after any prompt in some conversations

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

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?

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.

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.