Summary

• Problem: When thinking=low is set, the model produces internal thinking blocks. The reasoning auto-default (based on model capability) was also enabling reasoning delivery, causing thinking blocks to be formatted as "Reasoning:" text and delivered to WhatsApp/Telegram.
• Why it matters: Users see the model's internal reasoning in their chat messages, prefixed with "Reasoning:" in italics — confusing and leaking internal content.
• What changed: Skip auto-enabling reasoningLevel when thinkLevel is already set (not "off"). The two features serve the same purpose; enabling both causes the model's internal thinking to be exposed as visible chat messages.
• What did NOT change: Users who explicitly set /reasoning on still get reasoning output. Only the auto-default is suppressed when thinking is active.

Change Type (select all)

• Bug fix

Scope (select all touched areas)

• Gateway / orchestration
• Integrations

Linked Issue/PR

• Closes [Bug] Thinking blocks leak into WhatsApp delivery + stale text fragments appended to replies (2026.2.22-2) #24290
• Related Bug: Extended thinking leaks into WhatsApp messages instead of being hidden #24214 (same symptom, different reporter)

User-visible / Behavior Changes

With thinking=low/medium/high, thinking blocks are no longer delivered as visible "Reasoning:" messages to WhatsApp/Telegram/other channels. Downgrade to 2026.2.21-2 is no longer needed as a workaround.

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

Repro + Verification

Environment

• OS: any
• Model/provider: Anthropic / claude-opus-4-6
• Integration/channel: WhatsApp or Telegram

Steps

1. Configure thinking=low
2. Send a message via WhatsApp/Telegram
3. Before fix: Thinking content appears as "Reasoning:\n_internal reasoning text_" in chat
4. After fix: Only the actual response text is delivered

Expected

• Thinking blocks are hidden; only the text response is sent.

Actual (before fix)

• Full thinking content visible in chat, prefixed with "Reasoning:"

Evidence

• Trace/log snippets — verified that resolvedReasoningLevel stays "off" when thinkLevel is set, preventing thinking block extraction and formatting.

Human Verification (required)

• Verified scenarios: thinking=low + reasoning not explicitly set → reasoning stays off; thinking=off + reasoning-capable model → reasoning auto-enables as before.
• Edge cases checked: Explicit /reasoning on with thinking=low → reasoning still works (explicit overrides auto-default).
• What I did not verify: Live WhatsApp delivery (verified logic flow only).

Compatibility / Migration

• Backward compatible? Yes
• Config/env changes? No
• Migration needed? No

Failure Recovery (if this breaks)

• How to disable/revert this change quickly: Revert the thinkingActive guard in get-reply-directives.ts.
• Files/config to restore: src/auto-reply/reply/get-reply-directives.ts
• Known bad symptoms: If users want both thinking AND visible reasoning, they would need to explicitly set /reasoning on.

Risks and Mitigations

• Risk: Users who relied on auto-enabled reasoning with thinking models lose it.
  • Mitigation: They can explicitly enable reasoning via /reasoning on. The auto-default was causing a bug, not a feature.

🤖 AI-assisted (Claude). Lightly tested — verified logic flow and regression analysis.

Made with Cursor

Greptile Summary

Prevents auto-enabling reasoning when thinking is already active, fixing a bug where internal thinking blocks were being formatted and delivered as visible "Reasoning:" messages to WhatsApp/Telegram users.

The fix adds a simple guard thinkingActive that checks if resolvedThinkLevel is set and not "off" before auto-enabling reasoning based on model capabilities. This prevents the conflict between two features that serve similar purposes - both expose model internal reasoning, but through different mechanisms.

• Logic is sound: reasoning and thinking both expose model internal reasoning, so enabling both causes duplication/leakage
• Explicit /reasoning on still works as expected (bypasses auto-default)
• Backward compatible: users who want both can explicitly enable reasoning

Confidence Score: 5/5

• This PR is safe to merge with minimal risk
• Simple, well-scoped bug fix that adds a single conditional check to prevent conflicting features from being enabled simultaneously. The logic is straightforward, the comment explains the rationale clearly, and explicit user overrides are preserved.
• No files require special attention

_{Last reviewed commit: 0a5f3a1}