openclaw - 💡(How to fix) Fix Native Codex harness succeeds in explicit sessions but Feishu direct-session replies are not delivered [1 comments, 2 participants]

Summary

Native Codex app-server harness works in isolated CLI/explicit agent sessions, but when the same route is used for a Feishu direct-session agent, final replies were not delivered to the user. Rolling the agent back to the PI/OpenAI-Codex route restored Feishu direct-message replies and /status.

This may be a Feishu delivery integration issue specific to native Codex harness delivery defaults / session origin, rather than a Codex model/auth failure.

Environment

• OpenClaw: 2026.5.6 (c97b9f7)
• macOS: Darwin 25.4.0 / status reported macOS 26.4.1
• Node: v25.6.1
• Channel: Feishu WebSocket mode, multi-account setup (accounts 7/7 OK)
• Codex plugin enabled
• Affected agent route: Feishu direct session

What worked

A temporary isolated test agent using native Codex succeeded:

{
  "id": "codex-test",
  "model": "codex/gpt-5.5",
  "agentRuntime": { "id": "codex" }
}

Smoke result:

{
  "status": "ok",
  "provider": "codex",
  "model": "gpt-5.5",
  "agentHarnessId": "codex",
  "runner": "embedded",
  "winnerProvider": "codex"
}

A direct CLI/explicit smoke for the real agent after switching to native Codex also succeeded:

{
  "status": "ok",
  "provider": "codex",
  "model": "gpt-5.5",
  "agentHarnessId": "codex",
  "runner": "embedded",
  "winnerProvider": "codex"
}

What failed

The real Feishu direct-session agent was switched from the stable PI route:

{
  "model": "openai-codex/gpt-5.5",
  "agentRuntime": { "id": "pi" }
}

to native Codex:

{
  "model": "codex/gpt-5.5",
  "agentRuntime": { "id": "codex" }
}

The Feishu direct-session metadata was also pinned to the native route:

{
  "modelProvider": "codex",
  "model": "gpt-5.5",
  "agentHarnessId": "codex",
  "agentRuntimeOverride": "codex",
  "authProfileOverride": "openai-codex:<email>",
  "authProfileOverrideSource": "user"
}

After that, Feishu direct messages and /status did not show a reply to the user. Logs showed inbound recognition for /status but command result delivery failed:

feishu[neo]: received message from <user_open_id> in <chat_id> (p2p)
feishu[neo]: detected system command, using plain-text dispatch
feishu[neo]: system command dispatched (delivered=false)

Manual send attempts through the Feishu account also returned HTTP 400 in this state:

[tools] message failed: Request failed with status code 400 raw_params={"action":"send","channel":"feishu","accountId":"neo",...}

Gateway status still reported Feishu as healthy:

Feishu ON OK configured · accounts 7/7

Rollback restored Feishu usability

Rolling the agent and direct-session metadata back to the PI/OpenAI-Codex route restored user-visible Feishu replies and /status:

{
  "model": "openai-codex/gpt-5.5",
  "agentRuntime": { "id": "pi" }
}

Session metadata after rollback:

{
  "modelProvider": "openai-codex",
  "model": "gpt-5.5",
  "agentHarnessId": "pi",
  "agentRuntimeOverride": "pi",
  "authProfileOverride": "openai-codex:<email>"
}

PI smoke result:

{
  "status": "ok",
  "provider": "openai-codex",
  "model": "gpt-5.5",
  "agentHarnessId": "pi",
  "runner": "embedded",
  "winnerProvider": "openai-codex",
  "text": "Neo PI route ok。"
}

The user confirmed the Feishu direct chat and /status worked again after rollback.

Expected

If codex/gpt-5.5 + agentRuntime.id = "codex" succeeds in explicit/CLI sessions, the same agent runtime should either:

1. deliver final replies correctly through Feishu direct-session delivery, or
2. fail with an explicit surfaced delivery error explaining why the native Codex harness delivery mode is incompatible with this channel/account/session.

Instead, the model run could succeed in isolated smoke tests, while Feishu direct-session user-visible replies disappeared and /status command dispatch returned delivered=false.

Notes

This may be related to the Codex harness delivery default:

deliveryDefaults: {
  sourceVisibleReplies: "message_tool",
}

It may interact differently with Feishu direct-session reply/card delivery compared with the PI route.

I am filing this separately from the openai/gpt-* + agentRuntime=codex docs/routing mismatch because codex/gpt-5.5 itself does activate native Codex correctly in explicit sessions.