Summary

Describe the problem and fix in 2–5 bullets:

• Problem: DashScope OpenAI-compatible endpoints reject developer role on message payloads and return 400 errors.
• Why it matters: OpenClaw can fail immediately for DashScope/Qwen users when system prompts are emitted as developer role.
• What changed: treat DashScope-compatible openai-completions models as supportsDeveloperRole=false in compat normalization, with regression tests for provider-id and base-url detection.
• What did NOT change (scope boundary): no provider onboarding/auth flow changes and no generic role-mapping config surface added in this PR.

Change Type (select all)

• Bug fix
• Feature
• Refactor
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes Support DashScope (Alibaba Cloud Bailian) provider with role mapping (developer → system) #19130
• Related [Bug]: Model switching via /model command rejected despite valid allowlist config #20291

User-visible / Behavior Changes

DashScope-compatible endpoints now receive system role behavior (via compat supportsDeveloperRole=false) instead of developer, avoiding developer role 400s on these APIs.

Security Impact (required)

• New permissions/capabilities? (No)
• Secrets/tokens handling changed? (No)
• New/changed network calls? (No)
• Command/tool execution surface changed? (No)
• Data access scope changed? (No)
• If any Yes, explain risk + mitigation:

Repro + Verification

Environment

• OS: macOS
• Runtime/container: Node 22 / pnpm
• Model/provider: DashScope-compatible OpenAI-completions models
• Integration/channel (if any): N/A
• Relevant config (redacted): provider using DashScope endpoint host under models.providers.*.baseUrl

Steps

1. Configure a model using DashScope compatible endpoint (dashscope.aliyuncs.com, dashscope-intl.aliyuncs.com, or dashscope-us.aliyuncs.com).
2. Run model compat normalization path for that model.
3. Verify supportsDeveloperRole is forced to false.

Expected

• DashScope-compatible models disable developer-role emission.

Actual

• Tests pass and compat flag is applied for both provider-id and endpoint-host detection.

Evidence

Attach at least one:

• Failing test/log before + passing after
• Trace/log snippets
• Screenshot/recording
• Perf numbers (if relevant)

Human Verification (required)

What you personally verified (not just CI), and how:

• Verified scenarios: ran targeted tests for model compat and sessions patch paths.
• Edge cases checked: custom provider id with DashScope base URL still applies compatibility fallback.
• What you did not verify: live external DashScope API call in this PR run.

Compatibility / Migration

• Backward compatible? (Yes)
• Config/env changes? (No)
• Migration needed? (No)
• If yes, exact upgrade steps:

Failure Recovery (if this breaks)

• How to disable/revert this change quickly: revert src/agents/model-compat.ts commit.
• Files/config to restore: src/agents/model-compat.ts and related tests/changelog entry.
• Known bad symptoms reviewers should watch for: providers that intentionally require developer role but match DashScope host patterns.

Risks and Mitigations

• Risk: false-positive host match disables developer role where it is actually supported.
  • Mitigation: host match constrained to known DashScope endpoints plus explicit provider === "dashscope"; tests cover positive paths.

Greptile Summary

Added DashScope/Qwen API compatibility by setting supportsDeveloperRole=false for DashScope-compatible OpenAI endpoints. DashScope APIs reject the developer role and return 400 errors, so OpenClaw now sends system role instead. The fix follows the same pattern used for Z.ai and Moonshot providers, with detection via both explicit provider ID (dashscope) and base URL pattern matching (dashscope.aliyuncs.com, dashscope-intl.aliyuncs.com, dashscope-us.aliyuncs.com).

• Core logic change adds DashScope detection to normalizeModelCompat in src/agents/model-compat.ts:22
• Two new tests verify both provider-id and endpoint-host detection paths
• Changelog entry documents the user-facing fix
• Unrelated test added for sessions-patch model selection (appears to be bundled test coverage improvement)

Confidence Score: 5/5

• Safe to merge with no risk - straightforward compatibility fix
• Simple, well-tested compatibility flag that follows established patterns for Z.ai and Moonshot. Tests cover both detection paths (provider ID and base URL). No breaking changes or risky logic modifications.
• No files require special attention

_{Last reviewed commit: 759be86}