openclaw - ✅(Solved) Fix [Bug]: HTTP 400 — tools.profile=coding sends `read` tool schema without `additionalProperties: false`, rejected by OpenAI and GitHub Copilot providers [2 pull requests, 1 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#60821Fetched 2026-04-08 02:46:47
View on GitHub
Comments
0
Participants
1
Timeline
8
Reactions
0
Author
Participants
Timeline (top)
referenced ×6cross-referenced ×2

When tools.profile is set to coding (the default after running the Docker setup wizard), every agent turn fails with HTTP 400 because the built-in read tool schema is sent to the provider without additionalProperties: false, which OpenAI and GitHub Copilot providers require.

Error Message

  1. Observe the error immediately — no tool call is needed to trigger it. The error occurs on the first turn regardless of message content. Switching to a different provider (e.g. github-copilot/claude-sonnet-4.6) does not resolve it — the same 400 is returned. Error shown in the Control UI chat view on every turn: The error is consistent across all turns and both tested providers. Switching providers does not help.

Root Cause

When tools.profile is set to coding (the default after running the Docker setup wizard), every agent turn fails with HTTP 400 because the built-in read tool schema is sent to the provider without additionalProperties: false, which OpenAI and GitHub Copilot providers require.

Fix Action

Fix / Workaround

Workaround: set tools.profile to a profile that does not include the read tool, or disable the read tool explicitly:

PR fix notes

PR #60874: fix: add additionalProperties:false to tool schemas for OpenAI/Copilot providers

Description (problem / solution / changelog)

Summary

Built-in tool schemas (notably read) were missing additionalProperties: false, which OpenAI and GitHub Copilot providers require. This caused HTTP 400 on every agent turn for users with tools.profile: "coding" and OpenAI/Copilot models.

Error: HTTP 400: Invalid schema for function 'read': In context=(), 'additionalProperties' is required to be supplied and to be false.

Root Cause

The upstream pi-coding-agent package emits tool schemas (e.g. for read) without additionalProperties: false. The OpenAI and GitHub Copilot APIs require this field to be explicitly set to false on all function/tool object schemas.

Changes

src/agents/pi-tools.schema.ts

  • Added isOpenAIFamilyProvider detection (covers openai, openai-codex, github-copilot)
  • Added enforceAdditionalPropertiesFalse() helper that injects additionalProperties: false when targeting OpenAI-family providers
  • Hooked into applyProviderCleaning() so all schema paths (simple object schemas AND flattened union schemas) get the injection
  • For union/anyOf schemas: use false directly instead of defaulting to true when targeting OpenAI-family providers

src/agents/pi-tools.schema.test.ts

  • Added tests for openai provider (should inject additionalProperties: false)
  • Added tests for github-copilot provider (should inject additionalProperties: false)
  • Added tests for anthropic provider (should NOT inject — Anthropic is fine without it)

Approach

Option B (blanket fix in the schema normalization pass) — normalizeToolParameterSchema is the single point where all tool schemas are normalized before dispatch to providers, making it the right place for this fix. No tool-by-tool changes needed.

Fixes openclaw/openclaw#60821

Changed files

  • src/agents/pi-tools.schema.test.ts (modified, +51/-0)
  • src/agents/pi-tools.schema.ts (modified, +27/-2)

PR #60939: fix(msteams): replace deprecated HttpPlugin with httpServerAdapter

Description (problem / solution / changelog)

Summary

  • Migrate from the deprecated plugins: [noOpHttpPlugin] pattern to the SDK's public httpServerAdapter option in createMSTeamsApp()
  • Eliminates the [DEPRECATED] HttpPlugin in plugins array warning that fires every ~60s in the gateway error log
  • Removes ~40 lines of fragile code that used reflect-metadata hacks against internal SDK decorator paths

What changed

extensions/msteams/src/sdk.ts

  • Replaced the createNoOpHttpPlugin() function (~40 lines of reflect-metadata decorator hacks) with a 3-line createNoOpHttpServerAdapter() that implements IHttpServerAdapter
  • createMSTeamsApp() now passes httpServerAdapter instead of plugins: [noOpHttp]
  • Added type-only import for IHttpServerAdapter (dist subpath required — tsgo can't resolve the public barrel re-export chain)
  • Fixed stale JSDoc referencing removed HttpPlugin

extensions/msteams/src/sdk.test.ts

  • Updated test comment to reflect the new approach

Before / After

Before (main, unpatched) — HttpPlugin warning fires every ~60s (full log):

Apr 04 17:39:47 [WARN] @teams/app [DEPRECATED] HttpPlugin in plugins array will be deprecated...
Apr 04 17:40:47 [WARN] @teams/app [DEPRECATED] HttpPlugin in plugins array will be deprecated...
Apr 04 17:41:47 [WARN] @teams/app [DEPRECATED] HttpPlugin in plugins array will be deprecated...

After (this PR) — zero warnings over 2+ minute observation (full log):

Apr 04 17:42:49 [gateway] ready (6 plugins, 1.9s)
Apr 04 17:42:53 [msteams] starting provider (port 3979)
Apr 04 17:42:55 [msteams] users resolved: 11f44b5b...
(no HttpPlugin warnings)

Teams UI — bot receives messages, streams responses, shows AI label and feedback buttons:

Streaming and feedback working

Testing

  • All 7 existing msteams SDK tests pass
  • Deployed to Azure VM (riley-inbestments.westus2.cloudapp.azure.com) — before/after log comparison
  • msteams channel starts, users resolve, messages flow end-to-end
  • Verified in Teams via Playwright automation
  • Zero HttpPlugin deprecation warnings after sustained activity
  • Local gateway verified on macOS

Smoke test results (test plan)

TestResultNotes
A1 Basic replyPASSBot received and responded in 1:1 chat
A4 StreamingPASSTyping indicator + progress bar visible
A6 FeedbackPASSLike/Dislike buttons render on bot messages
E4 HTTPSPASScurl returns 401 (rejects unauthenticated)

All evidence: SidU/ocmaintenance/teams/testing/screenshots/2026-04-04/

Known issues (pre-existing, not caused by this PR)

  • openclaw/openclaw#60821: OpenAI strict mode rejects tool schemas missing additionalProperties: false and required arrays. This affects all tools (read, exec, cron) on main — not introduced by this change.

Fixes: https://github.com/openclaw/openclaw/issues/60732 See also: https://github.com/openclaw/openclaw/issues/55161

🤖 Generated with Claude Code

Changed files

  • CHANGELOG.md (modified, +1/-0)
  • extensions/msteams/src/sdk.test.ts (modified, +2/-3)
  • extensions/msteams/src/sdk.ts (modified, +16/-60)

Code Example

HTTP 400: Invalid schema for function 'read': In context=(), 'additionalProperties' is required to be supplied and to be false.

---

HTTP 400: Invalid schema for function 'read': In context=(), 'additionalProperties' is required to be supplied and to be false.

---

docker compose run --rm openclaw-cli config set tools.profile default
docker compose run --rm openclaw-cli restart
RAW_BUFFERClick to expand / collapse

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

When tools.profile is set to coding (the default after running the Docker setup wizard), every agent turn fails with HTTP 400 because the built-in read tool schema is sent to the provider without additionalProperties: false, which OpenAI and GitHub Copilot providers require.

Steps to reproduce

  1. Run the Docker setup wizard (./scripts/docker/setup.sh) — it sets tools.profile: "coding" by default.
  2. Start the gateway (docker compose up -d openclaw-gateway).
  3. Open the dashboard and send any message (e.g. "Hi") using any OpenAI or GitHub Copilot model.
  4. Observe the error immediately — no tool call is needed to trigger it.

Expected behavior

The read tool schema (and all built-in coding-profile tool schemas) should have additionalProperties: false injected before the request is sent to providers that enforce strict JSON Schema, so tool calls succeed normally.

Actual behavior

Every turn fails with:

HTTP 400: Invalid schema for function 'read': In context=(), 'additionalProperties' is required to be supplied and to be false.

The error occurs on the first turn regardless of message content. Switching to a different provider (e.g. github-copilot/claude-sonnet-4.6) does not resolve it — the same 400 is returned.

OpenClaw version

2026.4.4

Operating system

macOS 15 (host), Docker container (node:24-bookworm)

Install method

Docker (./scripts/docker/setup.sh + docker compose)

Model

openai/gpt-5.4 (primary), also reproduced with github-copilot/claude-sonnet-4.6

Provider / routing chain

openclaw -> openai openclaw -> github-copilot

Additional provider/model setup details

  • tools.profile: "coding" set in ~/.openclaw/openclaw.json (written by the setup wizard)
  • No MCP servers configured
  • No custom tool overrides
  • Reproduced with both primary and fallback models across two different providers

Logs, screenshots, and evidence

Error shown in the Control UI chat view on every turn:

HTTP 400: Invalid schema for function 'read': In context=(), 'additionalProperties' is required to be supplied and to be false.

The error is consistent across all turns and both tested providers. Switching providers does not help.

Impact and severity

  • Affected: Any user who installs via Docker (the setup wizard sets tools.profile: "coding" by default) and uses OpenAI or GitHub Copilot providers
  • Severity: Complete blocker — no messages can be processed at all
  • Frequency: 100% of turns, from the very first message
  • Consequence: The gateway is fully non-functional out of the box with the default Docker setup

Additional information

Workaround: set tools.profile to a profile that does not include the read tool, or disable the read tool explicitly:

docker compose run --rm openclaw-cli config set tools.profile default
docker compose run --rm openclaw-cli restart

Related issues: #29416, #58084 (similar schema validation failures but for different tools/contexts).

The root cause appears to be that the coding profile's built-in read tool schema is missing additionalProperties: false in the schema normalization path before it is serialized into the provider request. The AGENTS.md notes that native OpenAI-family routes default tool schemas to strict mode — but the normalization that injects additionalProperties: false does not appear to cover the built-in read tool.

extent analysis

TL;DR

Set additionalProperties: false in the read tool schema or switch to a profile that does not include the read tool to resolve the HTTP 400 error.

Guidance

  • The issue is caused by the missing additionalProperties: false in the read tool schema for the coding profile, which is required by OpenAI and GitHub Copilot providers.
  • To verify the issue, check the error message in the Control UI chat view, which should indicate an HTTP 400 error due to an invalid schema for the read function.
  • A temporary workaround is to set tools.profile to a profile that does not include the read tool, such as the default profile, using the command docker compose run --rm openclaw-cli config set tools.profile default.
  • To mitigate the issue, consider updating the read tool schema to include additionalProperties: false or disabling the read tool explicitly.

Example

No code snippet is provided as the issue is related to configuration and schema validation.

Notes

The root cause of the issue appears to be a missing normalization step for the built-in read tool schema in the coding profile. The provided workaround can help resolve the issue temporarily, but a permanent fix would require updating the schema or the normalization process.

Recommendation

Apply the workaround by setting tools.profile to a profile that does not include the read tool, such as the default profile, until a permanent fix is available. This will allow the gateway to function normally with the default Docker setup.

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

Expected behavior

The read tool schema (and all built-in coding-profile tool schemas) should have additionalProperties: false injected before the request is sent to providers that enforce strict JSON Schema, so tool calls succeed normally.

Still need to ship something?

×6

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

Back to top recommendations

TRENDING