Skip to content

[Bug]: codex_app__automation_update schema type is null, causing HTTP 400 on Codex endpoint #106277

Closed

Description

@xudonggang123

Bug type: Behavior bug

Beta release blocker: No

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:

  1. Install OpenClaw 2026.6.11 (e085fa1) with default config, using DeepSeek (deepseek-v4-flash) as the provider.
  2. Configure CC Switch local proxy and use Codex endpoint.
  3. 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'

OpenClaw version: 2026.6.11 (e085fa1)

Operating system: Windows 11

Install method: npm global

Model: deepseek/deepseek-v4-flash

Notes:

  • No user automations are configured. This is a default installation.
  • Config validation passes successfully.
  • Error only occurs when the Codex endpoint handles API calls to the DeepSeek provider, as DeepSeek validates function schemas strictly.

Reported by: (Andrew)

Activity

  1. xudonggang123 commented on Jul 13, 2026

    @xudonggang123
    Author
  2. added
    P2Normal backlog priority with limited blast radius.
    impact:auth-providerAuth, provider routing, model choice, or SecretRef resolution may break.
    on Jul 13, 2026
  3. clawsweeper commented on Jul 13, 2026

    @clawsweeper
    Contributor

    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.

  4. added 3 commits that reference this issue on Jul 13, 2026
    b5bb4f1
    8ea72b2
    764f465
  5. locked as resolved and limited conversation to collaborators on Sep 2, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    P2Normal backlog priority with limited blast radius.impact:auth-providerAuth, provider routing, model choice, or SecretRef resolution may break.

    Type

    No type

    Fields

    Priority

    None yet

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions