fix(deepseek): replay reasoning content for tool calls

[Jerry2003826]

Fixes #12246

Summary

• Add reasoning_content: "" to DeepSeek assistant messages when replaying chat history through the OpenAI-compatible adapter.
• Preserve any existing reasoning_content returned by DeepSeek instead of overwriting it.
• Add regression coverage for the assistant tool-call replay shape used by CLI tool-result loops.

Root Cause

The CLI path uses @continuedev/openai-adapters directly. Unlike the core OpenAI converter, the DeepSeek adapter did not add reasoning_content when replaying previous assistant messages. During a tool-call loop, DeepSeek's strict API gateway can reject the follow-up request after a local tool result because the previous assistant tool-call message lacks this field.

Validation

• npm test -- src/test/main.test.ts -t "DeepSeek" from packages/openai-adapters
• npm test -- src/test/main.test.ts from packages/openai-adapters
• npm test from packages/openai-adapters
• npm run build from packages/openai-adapters
• npx prettier --check packages/openai-adapters/src/apis/DeepSeek.ts packages/openai-adapters/src/test/main.test.ts

---

Summary by cubic

Ensure DeepSeek assistant tool-call replays include reasoning_content so follow-up requests aren’t rejected during CLI tool-result loops. Fixes #12246.

• Bug Fixes
  • Add reasoning_content: "" to assistant messages during replay in the OpenAI-compatible adapter.
  • Preserve existing reasoning_content when provided by DeepSeek.
  • Add regression tests for the CLI assistant tool-call replay shape.

^{Written for commit 5950948. Summary will update on new commits.}

[github-actions]

All contributors have signed the CLA ✍️ ✅
_{Posted by the CLA Assistant Lite bot.}

[cubic-dev-ai]

No issues found across 2 files

[Jerry2003826]

I have read the CLA Document and I hereby sign the CLA

[chatgpt-codex-connector]

💡 Codex Review

continue/gui/src/forms/AddModelForm.tsx

Lines 75 to 76 in 5950948

	setFetchedModelsList((prev) =>
	selectedProvider.provider === providerAtFetchTime ? models : prev,

Guard model-fetch response against stale provider switches

The stale-response check in handleFetchModels is ineffective because selectedProvider is captured from the same render as providerAtFetchTime, so selectedProvider.provider === providerAtFetchTime will always be true for that in-flight request. If a user starts fetching models for provider A and switches to provider B before the request resolves, the old response can still overwrite fetchedModelsList for the new provider, showing mismatched model options. Compare against current provider state at resolve time (e.g., via a ref/request token) instead of the closed-over value.

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[Jerry2003826]

CI note: the checks for the area touched by this PR are green, including packages-checks (openai-adapters). The remaining failure is jetbrains-tests, specifically the IntelliJ integration test Autocomplete > testAutocomplete() failing at Autocomplete.kt:42 after the Tab autocomplete assertion.

This looks unrelated to this PR's packages/openai-adapters change. I found the same Autocomplete.kt:42 failure in recent unrelated PR runs as well, for example:

• https://github.com/continuedev/continue/actions/runs/25574737914/job/75079009113
• https://github.com/continuedev/continue/actions/runs/25546110570/job/74982627951

I tried to rerun the failed job, but GitHub requires repository admin rights for that. Could a maintainer rerun jetbrains-tests when convenient?