openclaw - 💡(How to fix) Fix [Feature]: Option to use Codex OAuth billing with local gateway tool execution (decouple billing from Responses API) [1 participants]

Summary

Allow openai-codex/ models to use Codex OAuth authentication for billing while routing tool execution through OpenClaw's native gateway tools (exec, write, read) instead of the Codex Responses API's server-side execution.

Problem to solve

When using openai-codex/gpt-5.4 as the primary model in OpenClaw v2026.4.5, the Codex Responses API (chatgpt.com/backend-api) handles ALL tool execution server-side. File writes, shell commands via exec, and apply_patch operations all execute on OpenAI's servers and return results, but nothing persists to the local host filesystem.

This creates "phantom writes" -- the agent reports success and shows correct file content, but no files exist on disk. The local gateway never executes tools -- confirmed via strace (no file operations during message processing) and by disabling all ACP features (acp.enabled=false, ACPX plugin disabled, spawnAcpSessions=false) with no change in behavior.

The Codex OAuth subscription is a major cost optimization ($20/mo vs $100+/day API billing), but the server-side tool execution makes it unusable for any workflow requiring file persistence, code generation, or system administration.

OpenClaw docs and community confirm tools should execute locally ("the LLM acts purely as the brain, while actual execution of tools happens locally on your machine or VPS"). The openai-codex/ provider should be a billing/auth route, not an execution-model change.

Environment: v2026.4.5, Ubuntu 22.04, Telegram webhook mode, openai-codex/gpt-5.4

Proposed solution

Add a config option like agents.defaults.models["openai-codex/gpt-5.4"].toolExecution: "local" (or a provider-level openai-codex.localTools: true) that tells OpenClaw to:

1. Use Codex OAuth credentials for LLM API calls (billing through ChatGPT subscription)
2. 1. Parse tool_use blocks from the model response locally
3. 1. Execute tools through the gateway's native exec/write/read tools on the host
4. 1. Feed tool results back to the model for the next turn This is how openai/ and anthropic/ providers already work -- the model generates tool calls and OpenClaw executes them locally. The openai-codex/ provider should support the same pattern as an opt-in config.

Alternatives considered

1. Use openai/gpt-5.4 with API key -- same model, local tools work, but costs significantly more
2. 1. Use a non-OpenAI model for agents needing file writes -- loses GPT-5.4 capabilities
3. 1. Workaround architecture where agent outputs text and a separate process writes files -- defeats autonomous agent purpose

Impact

Affected: Any user running openai-codex/ models via Telegram, Discord, or other non-interactive channels who needs file persistence Severity: Blocks workflow -- agents cannot write code, configs, or any files to disk Frequency: Always (100% of tool calls with openai-codex/ routing) Consequence: Multi-agent teams cannot operate autonomously; all file operations require manual SSH intervention

Evidence/examples

Verified via strace on gateway PID during tool execution -- zero file operations on host. Agent reports successful echo/cat/ls output but files don't exist on disk. Behavior persists with all ACP features disabled (acp.enabled=false, ACPX plugin disabled). Related: #39316 (codex-cli sandbox defaults), #29195 (ACP permission silent failures), #33587 (codex-responses ignores tool calls).

Additional information

OpenClaw v2026.4.5, openai-codex/gpt-5.4 via ChatGPT Plus OAuth. Telegram channel with webhook mode on Ubuntu 22.04 VPS. The v2026.4.5 embedded ACPX runtime change (PR #61319) may be related -- older ACP sessions from pre-upgrade (v2026.4.2) had working local transcripts, post-upgrade sessions have 0-byte transcripts.