Summary

When the openai-codex provider (api openai-codex-responses, baseUrl
https://chatgpt.com/backend-api/codex) is invoked with a context whose
messages array is empty but whose systemPrompt is set, the resulting
request body contains input: []. ChatGPT's codex backend rejects this with
a 400:

One of "input" or "previous_response_id" or 'prompt' or 'conversation_id'
must be provided.

In practice the 400 closes the upstream socket before the streaming consumer
classifies the failure, so most calls surface to the user as a 15–31s
timeout rather than the underlying error — making this hard to diagnose
from logs alone. We caught the rawError on one occurrence:

[agent/embedded] embedded run agent end: ... isError=true model=gpt-5.5
  provider=openai-codex
  error=One of "input" or "previous_response_id" or 'prompt' or 'conversation_id' must be provided.
  rawError=One of "input" or "previous_response_id" or 'prompt' or 'conversation_id' must be provided.

with 27 sibling entries from the same workload showing
decision=surface_error reason=timeout from=openai-codex/gpt-5.5 for what
appears to be the same root cause.

Environment

• openclaw 2026.4.26
• macOS 15 (Darwin 25.4.0)
• Auth: ChatGPT OAuth (access_token still valid; not an auth failure)
• Triggering plugin: active-memory (memory-flush bootstrap run)
• Affected models: openai-codex/gpt-5.4, openai-codex/gpt-5.5

Root cause (suspected)

buildOpenAIResponsesParams in provider-stream-*.js:

```js
const messages = convertResponsesMessages(model, context, ..., {
includeSystemPrompt: !isCodexResponses, // codex skips system msg
supportsDeveloperRole
});
const params = {
model: model.id,
input: messages, // empty when caller has no user turn
stream: true,
...isCodexResponses ? { instructions: buildOpenAICodexResponsesInstructions(context) } : {},
...
};
```

For codex, the system prompt is moved out of messages into instructions
(correct per ChatGPT's codex contract). But if the caller passes
{ systemPrompt: "...", messages: [] } — which active-memory's flush
bootstrap does — params.input ends up as []. The codex backend
treats that as missing and 400s.

Proposed fix

Inside buildOpenAIResponsesParams, after the convertResponsesMessages
call, ensure codex requests carry at least one input item when the only
content available is the system prompt:

```js
if (isCodexResponses && messages.length === 0 && context.systemPrompt) {
messages.push({
role: "user",
content: [{
type: "input_text",
text: sanitizeTransportPayloadText(
stripSystemPromptCacheBoundary(context.systemPrompt)
)
}]
});
}
```

Alternatives considered:

• Set includeSystemPrompt: true for codex unconditionally — wrong, the
  ChatGPT codex backend expects system-as-instructions, not as a message.
• Refuse to dispatch when messages.length === 0 — surfaces a clearer
  error but doesn't restore functionality for the (legitimate) bootstrap case.

Repro

1. Configure an openai-codex provider with gpt-5.5 (or any
   openai-codex-responses model).
2. Enable active-memory plugin, set
   plugins.entries.active-memory.config.activeProvider = openai-codex,
   activeModel = gpt-5.5.
3. Trigger an active-memory flush (e.g. send a Slack message that
   crosses the flush threshold).
4. Observe `[agent/embedded] embedded run failover decision: ... reason=timeout from=openai-codex/gpt-5.5` in `gateway.err.log`.
5. Occasionally a single entry surfaces the underlying 400 rawError
   above.

Workaround

Point active-memory's activeProvider/activeModel at any non-codex
provider (e.g. an lmstudio-served model). Confirms codex is the
isolated failure point.