Summary

When the Codex harness synthesizes a missing_tool_result for a hung native bash call, the error percolates through the failover classification pipeline without matching any known provider-failure pattern. The outer runWithModelFallback loop in model-fallback.ts treats unrecognized errors as retryable when remaining model candidates exist (line 1789), causing a cross-provider model fallback that silently switches the user's model mid-conversation. No other provider/model can fix a local tool execution failure.

This fix adds detection of the Codex MISSING_TOOL_RESULT_ERROR text pattern in isNonProviderRuntimeCoordinationError, which is already checked at both the inner runner (line 366) and outer fallback loop (line 1717) in model-fallback.ts. When detected, the error is treated as a non-provider local failure and the fallback chain aborts immediately instead of consuming candidate slots.

Fixes #95474

Real behavior proof (required for external PRs)

Behavior addressed: Codex missing_tool_result (synthetic error for hung native tool calls) triggers cross-provider model fallback, silently switching the user's model mid-conversation to a different provider that also cannot fix the local tool failure.

Real setup tested:

• Runtime: Node 22.19, Linux 4.19.112-2.el8.x86_64
• Code analysis path: See root cause analysis below
• Test framework: Vitest 4.1.8

Root cause: The outer fallback loop in model-fallback.ts:1789 assumes all unrecognized (non-FailoverError) errors are retryable when remaining candidates exist. The Codex MISSING_TOOL_RESULT_ERROR ("OpenClaw recorded a native Codex tool.call without a matching tool.result before the turn completed.") does not match any failover classification pattern, so coerceToFailoverError returns null. The raw error becomes normalized at line 1737, isKnownFailover is false at line 1792, and the loop continues to the next model candidate — even though no other provider can fix a local command.

Exact steps or command run after this patch:

cd /home/0668001085/workspace/openclaw-worktrees/fix/issue-95474
node_modules/.bin/vitest run src/agents/failover-error.test.ts --config vitest.config.ts --reporter=verbose
node_modules/.bin/vitest run src/agents/model-fallback.test.ts --config vitest.config.ts --reporter=verbose
pnpm format:check src/agents/failover-error.ts src/agents/failover-error.test.ts

After-fix evidence:

✓ |unit-fast| failover-error > isNonProviderRuntimeCoordinationError > returns true for direct Codex missing native tool result errors
✓ |unit-fast| failover-error > isNonProviderRuntimeCoordinationError > returns true when the missing tool result error is nested via cause
✓ |unit-fast| failover-error > isNonProviderRuntimeCoordinationError > returns true when the missing tool result error is nested via error property
✓ |unit-fast| failover-error > isNonProviderRuntimeCoordinationError > returns false for unrelated error messages that mention 'tool'

 Test Files  1 passed (1)
      Tests  95 passed (95)

 Test Files  2 passed (2)
      Tests  164 passed (164)  (model-fallback regression suite)

$ pnpm format:check src/agents/failover-error.ts src/agents/failover-error.test.ts
Checking formatting...
All matched files use the correct format.
Finished in 18ms on 2 files using 1 threads.

Observed result after the fix: isNonProviderRuntimeCoordinationError now returns true for errors containing the Codex MISSING_TOOL_RESULT_ERROR pattern (both direct and nested via cause/error properties). The model fallback chain will abort on these local tool execution failures instead of advancing to the next candidate. All existing tests continue to pass with no regressions.

What was not tested: Live end-to-end reproduction with a hung Codex bash call. The fix is validated at the source level with unit tests covering the exact error message shape the Codex harness produces during synthesizeMissingToolResults (confirmed by ClawSweeper source-repro review).

Tests and validation

Risk checklist

Did user-visible behavior change? Yes - Users encountering hung Codex native tool calls will no longer see their model silently switch to a different provider. The error will surface as a terminal error on the same model, which is the intended behavior.

Did config, environment, or migration behavior change? No

Did security, auth, secrets, network, or tool execution behavior change? No

Current review state

What is the next action? Maintainer review requested