fix(config): add dropReasoningFromHistory config for openai-completions providers (#88068)

Summary

Problem

All openai-completions type models (strict OpenAI-compatible providers) unconditionally strip reasoning/thinking blocks (e.g. reasoning_content) from replayed conversation history, with no configuration option to override this behavior.

This breaks models like Qwen3.6 series that use preserve_thinking functionality and rely on reasoning content from previous turns being preserved in multi-turn conversations.

Impact: Users with custom model providers using openai-completions API + models that emit reasoning blocks cannot prevent the stripping behavior, degrading response quality when thinking mode is enabled.

Root cause

• resolveTranscriptPolicy() in src/agents/transcript-policy.ts had hardcoded logic that defaults to stripping reasoning content for all strict OpenAI-compatible (isStrictOpenAiCompatible) providers
• No config path existed to pass an override value into the policy resolution function
• The TranscriptPolicy type lacked a dropReasoningFromHistory field entirely
• Provider schema (ModelProviderSchema) used .strict() mode which rejected any unknown keys

What changed

1. Added dropReasoningFromHistory: boolean to TranscriptPolicy type - new field controls whether reasoning blocks are stripped from replayed history
2. Extended resolveTranscriptPolicy() signature - accepts optional dropReasoningFromHistory override parameter; defaults to true for openai-completions (strict OpenAI-compatible) providers, false otherwise
3. Added schema support - ModelProviderSchema now accepts dropReasoningFromHistory?: boolean config key
4. Updated type definitions - ModelProviderConfig in types.models.ts includes the new optional field
5. Wired up config propagation:
   • attempt.ts:557-562 - reads from params.config?.models?.providers?.[provider]?.dropReasoningFromHistory
   • compact.ts:528-534 - same pattern for compaction path
6. Added regression tests - 5 test cases covering default behavior, explicit override, and edge cases

What did NOT change

• Default behavior for existing users: openai-completions providers still strip reasoning by default (backward compatible)
• No changes to actual stripping logic itself (that's handled downstream by session transcript repair)
• No changes to other TranscriptPolicy fields or provider detection logic
• No changes to package.json or pnpm-lock.yaml

Change Type

• Bugfix (non-breaking change fixing reported problem)
• Feature (new non-breaking functionality)
• Refactor (restructuring code, no behavior change)
• Breaking Change (fix/feature causing existing valid configs to fail)
• Documentation-only update
• Dependency update

Scope

Areas modified

• Config/Schema - Added dropReasoningFromHistory to ModelProviderSchema and ModelProviderConfig
• Agent Core - Extended resolveTranscriptPolicy() with override parameter
• Runner/Compaction - Wired config value through to policy resolution in both paths
• Tests - Added regression tests for new behavior
• Channels/Messaging - Not affected
• Extensions/Plugins - Not affected
• Documentation - Not updated (user-facing docs not required for config key addition per issue severity)

Linked Issue/PR

Closes #88068

Related issues:

• [Bug]: Empty responses from OpenAI-compatible models with reasoning #81058 (same root cause, previously gave incorrect workaround suggesting dropReasoningFromHistory key that didn't exist in schema)

Security Impact

Does this change touch auth, secrets, crypto, networking, or permissions?

No - This change only adds a boolean configuration flag for conversation history handling logic. It does not:

• Modify authentication flows or token handling
• Access or expose sensitive data (API keys, tokens, credentials)
• Change network request patterns or endpoints
• Alter permission checks or access control lists
• Introduce code execution paths or command injection vectors
• Modify file system access patterns beyond reading existing config

Could this change enable privilege escalation, data exfiltration, or unauthorized access?

No - The new flag is purely declarative (boolean toggle) and only affects whether reasoning content is included in conversation history sent to LLM APIs. It cannot be exploited for security bypasses because:

• It does not grant additional capabilities or permissions
• It does not modify validation or sanitization of user input
• It does not change how API calls are authenticated or authorized
• The worst case (setting false) preserves more context in history, which is less risky than the default stripping behavior

Are there sensitive values in logs, error messages, or diagnostics exposed by this change?

No - The change does not add any logging, error messages, or diagnostic output. Existing logging in transcript-policy.ts is unchanged.

Reproduction + Verification

Environment

Steps to reproduce original issue (before fix)

1. Configure custom model provider with api: "openai-completions" and a model emitting reasoning_content (e.g., Qwen3.6 via llama.cpp)
2. Start multi-turn conversation with thinking/reasoning enabled
3. Observe reasoning blocks stripped from replayed history on subsequent turns
4. Attempt to set dropReasoningFromHistory: false in provider config → validation rejects unknown key

Steps to verify fix

1. Apply this PR's changes to local checkout
2. Add "dropReasoningFromHistory": false to provider config in openclaw.json under models.providers.<provider-name>
3. Restart gateway / run agent with configured provider
4. Verify config validation passes (schema accepts new key)
5. Verify reasoning blocks preserved in multi-turn conversations (or check transcriptPolicy.dropReasoningFromHistory === false in debug logs if available)
6. Run unit tests: pnpm vitest run src/agents/transcript-policy.test.ts

Real Behavior Proof

• Behavior or issue addressed: Before fix, all openai-completions providers unconditionally stripped reasoning/thinking blocks from history at src/agents/transcript-policy.ts:134-137 with no config override path. After fix, users can set dropReasoningFromHistory: false in provider config to preserve reasoning blocks.
• Real environment tested: Windows 11, Node.js v22.17.1, branch fix/88068-drop-reasoning-config-upstream
• Exact steps or command run after fix: Step 1 ran pnpm tsgo --noEmit returning zero TypeScript errors across modified files. Step 2 ran pnpm format -- <modified files> returning exit code 0 (all formatted). Step 3 read source trace at transcript-policy.ts:78-82 confirming new parameter signature accepts dropReasoningFromHistory?: boolean. Step 4 traced at zod-schema.core.ts:237-238 confirming schema field added with JSDoc documentation. Step 5 traced at attempt.ts:557-562 and compact.ts:528-534 confirming config propagation from params.config?.models?.providers?.[provider]?.dropReasoningFromHistory.
• After-fix evidence: Source trace at transcript-policy.ts:134-137 shows default resolution logic: params.dropReasoningFromHistory ?? (isStrictOpenAiCompatible ? true : false). Terminal output: pnpm format completed in 291ms on 6 files using 8 threads. Lint check returned 0 errors. Type check passed with no errors related to modified files.
• Observed result after fix: Schema accepts dropReasoningFromHistory without validation errors. Config value propagates through both attempt.ts and compact.ts call sites to resolveTranscriptPolicy(). New test suite covers 5 scenarios: default true for openai-completions, explicit false override, default false for official OpenAI, default false for OpenRouter, and explicit true override for non-default providers.
• What was not tested: End-to-end integration with live LLM API (requires running gateway with real provider). Actual runtime behavior of preserving vs stripping reasoning blocks in session file (depends on downstream consumer of TranscriptPolicy.dropReasoningFromHistory). Edge cases with concurrent config reloads or hot-reload scenarios.

Compatibility / Migration

Backward compatibility

✅ Fully backward compatible - Default behavior unchanged:

• For existing openai-completions providers without the new config key: dropReasoningFromHistory defaults to true (stripping enabled), matching pre-fix behavior
• For all other providers (OpenAI official, OpenRouter, etc.): defaults to false, also matching pre-fix implicit behavior
• No existing configs break - new field is optional in schema
• No migration needed for existing deployments

Migration path for users wanting to preserve reasoning

{
  "models": {
    "providers": {
      "my-qwen-provider": {
        "baseUrl": "http://localhost:8080",
        "api": "openai-completions",
        "dropReasoningFromHistory": false,
        "models": [
          { "id": "qwen3.6-35b", "name": "Qwen3.6 35B", "reasoning": true }
        ]
      }
    }
  }
}

Deprecations or removals

None - This is a pure additive feature

Failure Recovery

What happens if config is invalid?

If user provides non-boolean value (e.g. string "false" instead of boolean false), Zod schema validation rejects it at startup with clear error message pointing to models.providers.<name>.dropReasoningFromHistory.

What happens if field is missing?

Field is optional - falls back to default behavior based on provider type (as described above).

Rollback plan

To rollback this change:

1. Remove dropReasoningFromHistory field from TranscriptPolicy type
2. Remove parameter from resolveTranscriptPolicy() signature
3. Remove field from ModelProviderSchema and ModelProviderConfig
4. Remove config propagation lines in attempt.ts and compact.ts
5. Remove test cases from transcript-policy.test.ts
6. Redeploy - all existing configs continue working as before

Monitoring recommendations

No specific metrics or alerts needed - this is a passive config flag with no runtime performance implications.