You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Bug]: codex_app__automation_update schema type is null, causing HTTP 400 on Codex endpoint #106277
Summary:
Codex endpoint /responses returns HTTP 400 from DeepSeek due to invalid JSON Schema for the internal function codex_app__automation_update. Schema must be of type: "object", but got type: null.
Steps to reproduce:
Install OpenClaw 2026.6.11 (e085fa1) with default config, using DeepSeek (deepseek-v4-flash) as the provider.
Configure CC Switch local proxy and use Codex endpoint.
Observe upstream HTTP 400 error with the schema validation message.
Expected behavior:
All function schemas passed to the upstream provider should contain valid JSON Schema definitions with type: "object" where applicable.
Actual behavior:
Error logged: Invalid schema for function 'codex_app__automation_update': schema must be a JSON Schema of 'type: "object"', got 'type: null'
Thanks for writing this up. I checked the repo boundary, and this lives outside the OpenClaw source shell.
The failing schema belongs to Codex’s native automation_update tool as forwarded through the third-party CC Switch Codex proxy, while OpenClaw’s supported DeepSeek path uses the dedicated DeepSeek provider rather than the Codex runtime.
So I’m closing this as outside the OpenClaw source repository rather than keeping it open as core work.
Review details
Best possible solution:
Use OpenClaw’s dedicated DeepSeek provider for deepseek/deepseek-v4-flash; if CC Switch must proxy a Codex session, report or normalize the native automation_update schema in CC Switch or the Codex app/runtime that emits it, not in OpenClaw’s bridged-tool layer.
Do we have a high-confidence way to reproduce the issue?
No, not as an OpenClaw current-main defect: the supplied steps reproduce a CC Switch/Codex-to-DeepSeek compatibility failure, while the supported OpenClaw DeepSeek route is a separate provider path.
Is this the best way to solve the issue?
No; patching OpenClaw’s dynamic-tool bridge would target the wrong owner because the named automation tool is native to Codex. The narrow solution is to use the supported DeepSeek provider or fix schema normalization in the component emitting or proxying that native tool.
Security review:
Security review: This issue has no proposed patch and does not report a concrete security-boundary failure.
AGENTS.md: found and applied where relevant.
What I checked:
Tool ownership: Independent Codex Desktop reports show automation_update among the native per-thread tools even outside OpenClaw, establishing that this tool is supplied by the Codex app/runtime rather than OpenClaw’s bridged tool catalog.
Upstream Codex contract: Codex app-server documents dynamic tools as input supplied to thread/start, with each inputSchema expected to be a JSON Schema object; Codex itself builds the model-facing Responses tool list from native and dynamic tool specifications. (extensions/codex/src/app-server/thread-lifecycle.ts:1, b0ebb81e89f5)
OpenClaw boundary: OpenClaw’s Codex integration wraps OpenClaw-owned tools through its dynamic-tool bridge, while native Codex tools remain owned and executed by the downstream Codex app-server runtime. (extensions/codex/src/app-server/dynamic-tools.ts:36, b0ebb81e89f5)
Supported DeepSeek route: Current OpenClaw documentation provides a dedicated @openclaw/deepseek-provider installation and deepseek/deepseek-v4-flash model route with tool-follow-up compatibility; it does not direct DeepSeek traffic through the native Codex runtime or CC Switch. Public docs: docs/providers/deepseek.md. (docs/providers/deepseek.md:1, b0ebb81e89f5)
Provider/runtime separation: The agent-runtime documentation distinguishes providers from runtimes and describes the Codex runtime as the native backend for OpenAI/Codex model routes, not as the supported DeepSeek transport. Public docs: docs/concepts/agent-runtimes.md. (docs/concepts/agent-runtimes.md:1, b0ebb81e89f5)
Current-main check: Current main still documents the direct DeepSeek plugin route and the Codex/OpenAI runtime boundary; no OpenClaw-owned codex_app__automation_update definition was identified. Public docs: docs/providers/deepseek.md. (docs/providers/deepseek.md:1, b0ebb81e89f5)
Likely related people:
steipete: Recent merged history repeatedly touches the OpenClaw Codex app-server runner, configuration, and documented runtime boundary, making this the best OpenClaw-side routing contact if the boundary later proves incomplete. (role: recent Codex app-server contributor; confidence: medium; commits: f12e9c41fa15, c22f414c6976, df70ed2b9cd3; files: extensions/codex/src/app-server/run-attempt.ts, extensions/codex/src/app-server/config.ts, docs/plugins/codex-harness.md)
Codex review notes: model internal, reasoning high; reviewed against b0ebb81e89f5.
Activity
xudonggang123 commentedon Jul 13, 2026
clawsweeper commentedon Jul 13, 2026
Thanks for writing this up. I checked the repo boundary, and this lives outside the OpenClaw source shell.
The failing schema belongs to Codex’s native
automation_updatetool as forwarded through the third-party CC Switch Codex proxy, while OpenClaw’s supported DeepSeek path uses the dedicated DeepSeek provider rather than the Codex runtime.So I’m closing this as outside the OpenClaw source repository rather than keeping it open as core work.
Review details
Best possible solution:
Use OpenClaw’s dedicated DeepSeek provider for
deepseek/deepseek-v4-flash; if CC Switch must proxy a Codex session, report or normalize the nativeautomation_updateschema in CC Switch or the Codex app/runtime that emits it, not in OpenClaw’s bridged-tool layer.Do we have a high-confidence way to reproduce the issue?
No, not as an OpenClaw current-main defect: the supplied steps reproduce a CC Switch/Codex-to-DeepSeek compatibility failure, while the supported OpenClaw DeepSeek route is a separate provider path.
Is this the best way to solve the issue?
No; patching OpenClaw’s dynamic-tool bridge would target the wrong owner because the named automation tool is native to Codex. The narrow solution is to use the supported DeepSeek provider or fix schema normalization in the component emitting or proxying that native tool.
Security review:
Security review: This issue has no proposed patch and does not report a concrete security-boundary failure.
AGENTS.md: found and applied where relevant.
What I checked:
automation_updateamong the native per-thread tools even outside OpenClaw, establishing that this tool is supplied by the Codex app/runtime rather than OpenClaw’s bridged tool catalog.thread/start, with eachinputSchemaexpected to be a JSON Schema object; Codex itself builds the model-facing Responses tool list from native and dynamic tool specifications. (extensions/codex/src/app-server/thread-lifecycle.ts:1, b0ebb81e89f5)extensions/codex/src/app-server/dynamic-tools.ts:36, b0ebb81e89f5)@openclaw/deepseek-providerinstallation anddeepseek/deepseek-v4-flashmodel route with tool-follow-up compatibility; it does not direct DeepSeek traffic through the native Codex runtime or CC Switch. Public docs:docs/providers/deepseek.md. (docs/providers/deepseek.md:1, b0ebb81e89f5)docs/concepts/agent-runtimes.md. (docs/concepts/agent-runtimes.md:1, b0ebb81e89f5)codex_app__automation_updatedefinition was identified. Public docs:docs/providers/deepseek.md. (docs/providers/deepseek.md:1, b0ebb81e89f5)Likely related people:
extensions/codex/src/app-server/run-attempt.ts,extensions/codex/src/app-server/config.ts,docs/plugins/codex-harness.md)Codex review notes: model internal, reasoning high; reviewed against b0ebb81e89f5.
fix(ai): return default empty object schema when tool parameters is null
test(codex): add regression test for null tool parameters (openclaw#1…
fix(ai): correct null tool parameters to empty object schema without …
fix(codex): structured abort detection, tool-schema repair, native-re…
fix(codex): structured abort detection, tool-schema repair, native-re…
fix(codex): structured abort detection, tool-schema repair, native-re…