Issue Station
Sign In
Tools hereToolbox

openclaw - 💡(How to fix) Fix Agents routed through openai-codex / openai-codex-responses can reply as if tools executed without actually executing them [2 comments, 3 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#51063•Fetched 2026-04-08 01:04:44
View on GitHub
Comments
2
Participants
3
Timeline
3
Reactions
0
Author
glfruitglfruit
Participants
cgdusekcgdusekglfruitglfruitRyceRyce
Timeline (top)
commented ×2cross-referenced ×1

In some OpenClaw agent runs, when the selected model/provider path resolves to openai-codex / openai-codex-responses, the agent can produce execution-like status text such as:

  • “Executing these exact commands now”
  • “Running now”
  • “I’ll return with outputs”

…but no real tool execution happens:

  • no tool call events
  • no file writes
  • no command output
  • no clear runtime error saying tools are unsupported on this path

This creates a dangerous “promise-only” failure mode where the assistant sounds like it is working, but nothing was actually executed.

Error Message

In affected runs, the agent responds as if it is executing tools, for example:

Root Cause

This failure mode is especially risky because it is not obviously broken.

It can make an operator believe the system:

  • ran commands
  • edited files
  • completed work

…when in fact it only generated execution-sounding text.

For operational and multi-agent workflows, this is much more dangerous than a direct error.

Fix Action

Temporary workaround

Our local workaround so far is:

  • move tool-heavy agents away from the codex path
  • use a provider/model path already verified to execute tools correctly

This avoids the silent fake-execution behavior, but it would be better if OpenClaw either supported the codex path cleanly or failed loudly.

RAW_BUFFERClick to expand / collapse

Summary

In some OpenClaw agent runs, when the selected model/provider path resolves to openai-codex / openai-codex-responses, the agent can produce execution-like status text such as:

  • “Executing these exact commands now”
  • “Running now”
  • “I’ll return with outputs”

…but no real tool execution happens:

  • no tool call events
  • no file writes
  • no command output
  • no clear runtime error saying tools are unsupported on this path

This creates a dangerous “promise-only” failure mode where the assistant sounds like it is working, but nothing was actually executed.

Environment

  • OpenClaw installed version: 2026.3.13
  • Also checked current upstream main locally (commit 4c60956)
  • Affected provider path appears to involve:
    • openai-codex
    • openai-codex-responses

Observed behavior

In affected runs, the agent responds as if it is executing tools, for example:

“Executing these exact commands now” “Running now. I’ll return with raw command outputs only.”

But in reality:

  • no tool execution occurs
  • no artifacts are created
  • no command outputs are returned
  • the run may later admit it has not actually executed anything

This is worse than a hard failure because it silently degrades into a fake execution narrative.

Expected behavior

If the selected provider/model path cannot support OpenClaw agent tool execution, OpenClaw should do one of the following:

  1. Actually execute the tools, or
  2. Fail clearly and immediately with an explicit incompatibility error

It should not produce “I am executing now” style responses without real execution.

Evidence / reproduction signals

1. Real local symptom

A content-team agent (content-maya) was observed to fail in OpenClaw agent mode when routed through a codex path. After moving that agent away from the codex path to zai/glm-5-turbo, a simple write test succeeded again.

This suggests the failure is path/provider-specific, not just prompt-specific.

2. Community report with matching symptom

There is a public community report describing the same behavioral pattern: https://www.answeroverflow.com/m/1481742542474055791

The wording in that report is very similar to what we observed locally.

3. Current codebase signals

In both the installed build and current main, openai-codex-responses is still present and actively maintained.

Relevant files from current main:

  • extensions/openai/openai-codex-catalog.ts
  • extensions/openai/openai-codex-provider.ts
  • src/agents/pi-embedded-runner/openai-stream-wrappers.ts
  • src/agents/model-tool-support.ts

There is also still a generic compat gate where compat.supportsTools === false disables tool support.

I’m not claiming this alone proves the root cause, but it does suggest that the issue may live in the codex provider/transport/compat path rather than in model capability itself.

Important clarification

This issue is not claiming:

  • “OpenAI does not support tools”
  • “gpt-5.4 does not support tools”

The narrower concern is:

In OpenClaw agent mode, some runs that resolve through openai-codex / openai-codex-responses appear to degrade into execution-like text responses instead of real tool execution or a hard incompatibility error.

So this may be a provider-path / transport / adapter / compat-layer issue, not a model-family issue.

Why this matters

This failure mode is especially risky because it is not obviously broken.

It can make an operator believe the system:

  • ran commands
  • edited files
  • completed work

…when in fact it only generated execution-sounding text.

For operational and multi-agent workflows, this is much more dangerous than a direct error.

Suggested improvements

Any of these would be a major improvement:

  1. Hard fail early

    • If a selected model/provider path does not support tool execution in agent mode, fail before generating execution-like text.

  2. Runtime guard

    • If the model starts emitting execution-status text without any actual tool call event, surface a warning or convert the run into a failure.

  3. Provider-path diagnostics

    • Log clearly when a run resolves to openai-codex-responses
    • and whether tools are actually enabled/disabled on that resolved model object.

  4. Config-time warning

    • Warn when a tool-heavy agent is configured with a provider/path that may not support tools in OpenClaw agent mode.

Temporary workaround

Our local workaround so far is:

  • move tool-heavy agents away from the codex path
  • use a provider/model path already verified to execute tools correctly

This avoids the silent fake-execution behavior, but it would be better if OpenClaw either supported the codex path cleanly or failed loudly.

If helpful

I can also provide:

  • a smaller reproducible config snippet
  • the exact local agent configuration that triggered the behavior
  • a minimal “write a file” reproduction case

extent analysis

Fix Plan

To address the issue, we will implement a combination of the suggested improvements:

  1. Hard fail early: Check if the selected model/provider path supports tool execution in agent mode before generating execution-like text.
  2. Runtime guard: Monitor the model's output for execution-status text without actual tool call events and surface a warning or convert the run into a failure.
  3. Provider-path diagnostics: Log clearly when a run resolves to openai-codex-responses and whether tools are actually enabled/disabled on that resolved model object.

Step-by-Step Solution:

  • Update openai-codex-provider.ts to include a check for tool execution support:
if (!compat.supportsTools) {
  throw new Error('Tool execution not supported on this provider path');
}
  • Modify openai-stream-wrappers.ts to monitor the model's output for execution-status text:
if (output.includes('Executing') && !toolCallEvent) {
  console.warn('Execution-status text without tool call event');
  // Convert the run into a failure or surface a warning
}
  • Add logging in openai-codex-catalog.ts to indicate when a run resolves to openai-codex-responses:
console.log('Resolved to openai-codex-responses');
console.log(`Tools enabled: ${compat.supportsTools}`);
  • Update model-tool-support.ts to include a config-time warning for tool-heavy agents with incompatible provider paths:
if (agentConfig.toolHeavy && !providerPath.supportsTools) {
  console.warn('Tool-heavy agent configured with incompatible provider path');
}

Verification

To verify the fix, test the OpenClaw agent with the following scenarios:

  • A tool-heavy agent configured with a provider path that supports tool execution
  • A tool-heavy agent configured with a provider path that does not support tool execution (e.g., openai-codex-responses)
  • A non-tool-heavy agent configured with a provider path that supports tool execution

Extra Tips

  • Regularly review and update the provider paths and their corresponding tool execution support to prevent similar issues in the future.
  • Consider adding additional logging and monitoring to detect and respond to similar issues proactively.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Temporary workaround

Our local workaround so far is:

  • move tool-heavy agents away from the codex path
  • use a provider/model path already verified to execute tools correctly

This avoids the silent fake-execution behavior, but it would be better if OpenClaw either supported the codex path cleanly or failed loudly.

Expected behavior

If the selected provider/model path cannot support OpenClaw agent tool execution, OpenClaw should do one of the following:

  1. Actually execute the tools, or
  2. Fail clearly and immediately with an explicit incompatibility error

It should not produce “I am executing now” style responses without real execution.

#api#ssr#installation#tensor shape#cache error#pipeline error#runtime error#dependency conflict#environment setup

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

openclaw - 💡(How to fix) Fix Agents routed through openai-codex / openai-codex-responses can reply as if tools executed without actually executing them [2 comments, 3 participants]