Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Cursor LLM gateway config is a no-op: writes settings Cursor never reads

Aperta
  • Qualcosa non va?
#6,293 4 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@stantheman0128 ci sta già lavorando.

Dal 4/9/2026.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
go
Ambito
cli, tooling

Direzione di ricerca

Inizia da pkg/client/config.go:485-521 e pkg/client/llm_gateway.go:39-89, quindi segui il percorso di Cursor utilizzato da thv llm setup --client cursor. Determina se Cursor dispone di una superficie di configurazione affidabile e supportata oppure se il client debba essere contrassegnato come non supportato; il lavoro è completato quando il comportamento scelto è implementato e setup non dichiara più silenziosamente il successo per un’integrazione inefficace.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Summary

thv llm setup --client cursor reports success and patches ~/Library/Application Support/Cursor/User/settings.json with:

"cursor.general.openAIBaseURL": "http://localhost:14000/v1",
"cursor.general.openAIAPIKey": "thv-proxy"

(pkg/client/config.go:517-519, via ConfigureLLMGateway in pkg/client/llm_gateway.go). The gateway proxy (thv llm proxy start) starts and responds correctly. But nothing changes in Cursor: Settings → Models → "Override OpenAI Base URL" stays off, and manually switching it on shows the stock default (https://api.openai.com/v1), not the value from settings.json.

Root cause

Checked directly against the installed Cursor client (workbench.desktop.main.js, Cursor 3.15.19). The keys ToolHive writes — openAIBaseURL / openAIAPIKey (with that exact casing, under cursor.general.*) — do not appear anywhere in the bundle. The feature Cursor actually has is openAIBaseUrl (lowercase Url) plus a separate useOpenAIKey boolean, and both are read and written exclusively through Cursor's own internal state store, not the standard VS Code configuration service:

this.reactiveStorageService.applicationUserPersistentStorage.openAIBaseUrl ?? "https://api.openai.com/v1"
...
i.setApplicationUserPersistentStorage("openAIBaseUrl", v)
i.setApplicationUserPersistentStorage("useOpenAIKey", !0)

There is no code path in the bundle that reads cursor.general.openAIBaseURL (or any cursor.general.* key) from settings.json for this feature. So ConfigureLLMGateway for Cursor patches a file/key that the current app never consults — thv llm setup succeeds and reports nothing wrong, but the integration silently does nothing.

I have not yet located where applicationUserPersistentStorage actually persists to disk — a search of ~/Library/Application Support/Cursor/User/globalStorage/state.vscdb's ItemTable for openai/baseurl/apikey-like keys came up empty, so it's under a different key format, a different table, or a different storage file entirely.

Why this needs care, not just a key-name fix

applicationUserPersistentStorage is Cursor's own internal, undocumented storage mechanism — not a stable public API surface the way settings.json is. Even once the correct persistence location is found, writing into it directly is inherently more fragile than the settings.json approach ToolHive uses for every other client, and could silently break again on a future Cursor release. Worth deciding whether:

  1. It's worth reverse-engineering and writing to Cursor's private storage anyway (accepting the fragility), or
  2. Cursor should be marked as unsupported for the LLM gateway proxy-mode integration until/unless Cursor exposes a supported configuration surface for this, or
  3. Some other integration point exists (e.g. a documented settings key for a different mechanism, or an extension-based approach) that hasn't been checked yet.

Impact

Every thv llm setup --client cursor run to date has silently failed to configure Cursor, while reporting success. Given IsClientInstalled/DetectedLLMGatewayClients both consider Cursor supported and configured, this has presumably shipped since Cursor support was added and gone unnoticed.

References

  • pkg/client/config.go:485-521 (Cursor's clientAppConfig, including the LLMGatewayKeys specs)
  • pkg/client/llm_gateway.go:39-89 (ConfigureLLMGateway, the JSON-Pointer patch path used for Cursor)
  • Related: #6292 (Cursor/VSCode detection false negatives) — that issue is about detection; this one is about the actual configuration being applied being ineffective even when detection succeeds.
Lingua principale
Go
Stelle
2.3k
Fork
318
Merge medio
1g 21h
PR unite (30g)
96

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di stacklok/toolhive

Tutte le issue di stacklok/toolhive

Issue simili

Altre issue su Go

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.