- Refactored response handling in newProtoMessage to utilize agentv1 for GetUsableModelsResponse and GetDefaultModelForCliResponse.
- Added new tests for buildCLIModelDetails and encodeCLIModels to ensure correct model details and encoding.
- Updated buildUsableModelsPayload and buildDefaultModelForCliPayload to leverage buildCLIModelDetails for improved model data structure.
- Integrated a tooltip with a button to open the contributor's GitHub profile in the CursorAccountCard component.
- Updated the layout of the account card for better visual organization.
- Removed routing mode options from the configuration view and adjusted related translations in multiple languages.
- Cleaned up unused routing mode logic in the app state management.
Project sidecar context history into Cursor-compatible JSONL transcripts so previous conversations remain readable when referenced from new chats. Backfill existing sessions on startup and preserve Cursor-managed turn status entries during atomic updates.
Desktop Cursor works through the local proxy because it drives the agent
over BidiAppend/RunSSE plus the already-mocked unary endpoints. The
cursor-agent CLI speaks the same agent protocol but calls additional
unary endpoints that had no local handlers, so every request fell into a
wildcard route and came back as HTTP 404, which the Connect client maps
to '[unimplemented] HTTP 404'.
Three independent breaks, one visible symptom:
1. Startup: ServerConfigService/GetServerConfig (only the AiService
variant was mocked), DashboardService/GetTeamAdminSettingsOrEmptyIfNotInTeam
and DashboardService/ListMarketplaces were missing, so the CLI aborted
during session init.
2. Git workspaces: the CLI resolves the repo path-encryption key from
indexingConfig.default{User,Team}PathEncryptionKey in GetServerConfig
when no IDE-stored repo keys exist. The mock returned no indexingConfig,
so repository identity init failed with 'No encryption key found'.
3. Tool execution: every fs tool executor (Ls/Grep/Glob/Shell) consults
the ignore service, which calls getRepoBlockExcludeGlobs() ->
DashboardService/GetTeamReposOrEmptyIfNotInTeam. The 404 propagated as
the tool result error, so model answers arrived but every tool call
returned '[unimplemented] HTTP 404'. Non-git workspaces skip the
repo-block path, which is why tools only failed inside git repos.
Also close the remaining tolerated 404 noise so a CLI session produces
zero unimplemented responses: model listing (GetUsableModels,
GetDefaultModelForCli, GetDefaultModel), dashboard/plugin housekeeping
(GetGlobalCommands, GetEffectiveUserPlugins, RegisterMarketplaceAndPlugins,
GetCliDownloadUrl) and telemetry (AnalyticsService/SubmitLogs,
AnalyticsService/TrackEvents, OTLP /v1/traces).
Additional logging: PolicyMiddleware now includes the request path in the
per-request log line, which is what made this diagnosable from app.log.
Cursor may reuse the same request_id for a later turn and restart
append_seqno from 1. Accept seq=1 after progress as a sequence restart
when idle so tool results are not discarded as stale forever.
ModelAdapterModal.vue described OpenAI extra params as "合并到" (merge into)
the request body, but the backend (request_override.go:applyExtraParams)
writes body[name] = value — same-name fields are overridden, not merged.
This contradicted ModelEditor.vue's tooltip ("覆盖到...同名字段以这里为准")
and risked users expecting array fields like `tools` to be appended,
which would silently replace the built-in function tools.
Align the modal tooltip with the editor view and the actual override
semantics.
AnthropicAdapter.Stream built thinking config (buildAnthropicThinkingConfig)
and wrote it into body only inside the `if len(body)==0` normal-construction
block. The RequestBodyOverride branch skipped it entirely — a disabled effort
on the override path left whatever thinking config the override body carried,
violating user intent and diverging from openai.go, where
applyOpenAIThinkingDisable runs unconditionally after both branches.
Also, on the normal path, disabled only wrote thinking:{type:disabled} but
left a stale output_config (set by a prior adaptive turn or by
AnthropicExtraParams) in place — an explicitly disabled request could still
carry output_config.effort=high, a contradictory payload.
Fix:
- Extract applyAnthropicThinkingConfig(body, req), called unconditionally
after the override/normal block, mirroring openai.go:1860.
- disabled: force thinking:{type:"disabled"}, delete output_config, set
thinking_disabled_provider_param=thinking.type knob.
- adaptive (AnthropicThinkingEffort non-empty): write
thinking:{type:adaptive,display:summarized} + output_config.
- empty effort: no-op.
- buildAnthropicThinkingConfig retained for stable-message-count / message
normalization signals inside the normal block.
Tests: anthropic_thinking_disable_test.go covers all three branches, alias
normalization (off→disabled), disabled overriding existing adaptive config,
and the override-path symmetry scenario.
openAIThinkingDisableKind only matched dashscope/qwen/aliyun,
deepseek/bigmodel/z.ai/zhipu, and gpt-5.1+/gpt-6. Xiaomi MiMo
(api.xiaomimimo.com, model mimo-*) fell through to the default
branch, so when a user set reasoning=disabled the adapter wrote
no disable field and MiMo kept thinking enabled (extra latency +
reasoning token cost contrary to user intent).
Add xiaomimimo/mimo to the thinking_type case — MiMo uses the same
thinking:{type:"disabled"} shape as deepseek/glm, confirmed in
MiMo docs.
- openai.go: +2 conditions in openAIThinkingDisableKind
- openai_thinking_disable_test.go: cover MiMo (base/model/ultraspeed),
regress deepseek/glm/z.ai/qwen/gpt-5.1/gpt-6/unknown, and verify
applyOpenAIThinkingDisable writes thinking:{type:disabled} +
deletes reasoning_effort for MiMo
- Deleted outdated test files for OpenAI endpoint functionality.
- Improved the OpenAIEndpointURL function to better handle custom paths and version segments.
- Introduced a new helper function, stripEndpointVersionPrefix, to streamline endpoint processing.
- Introduced a new endpoint option for OpenAI integrations, allowing users to specify a custom path.
- Updated relevant components and validation logic to accommodate the new endpoint.
- Enhanced documentation and error messages to reflect the addition of the custom endpoint option.
leookun