Cursor integration: surface the Private Inference local-mode installer when only regular Cursor is installed #5679

Area

Multiple areas (Dashboard, Catalog / models, Documentation)

What are you trying to accomplish?

Use the installed Cursor Private Inference build with the Integrations → Cursor gateway values already shown by the dashboard:

• Base URL: http://127.0.0.1:<port>/v1
• API key: the existing loopback placeholder

Today the page reports the Private Inference build as missing when only regular Cursor is installed, even though Cursor now publishes a same-version local-mode installer.

What prevents this today?

Detection classifies an install only by product.json nameLong === "Cursor Private Inference" (src/integrations/cursor-detect.ts). A regular stable install is therefore always "regular", and the dashboard tells the user that a custom endpoint cannot reach loopback.

On Cursor 3.21.18 stable (Windows x64 user install), Private Inference is no longer only a separately named app:

• resources/app/product.json still has nameLong: "Cursor", quality: "stable", version 3.21.18.
• The same install contains extensions/cursor-local-agent-runtime, described as "Hosts Cursor Private Inference outside workspace extension hosts".
• The workbench resolves a Private Inference download during update when localMode is off and feature gate cursor_private_inference_download_prompt is on. The manifest request is <updateUrl>/api/update/<platform>/cursor-local/0.0.0/manual-check/stable.
• GET https://api2.cursor.sh/updates/api/update/win32-x64-user/cursor-local/0.0.0/manual-check/stable returns HTTP 200 with a same-version user installer:

{"version":"3.21.18","url":"https://downloads.cursor.com/local-mode/c4730f7d93d787d9ab120af715999f0345ee5bc5/win32/x64/user-setup/CursorUserSetup-x64-3.21.18.exe","productVersion":"3.21.18"}

The system-setup URL for win32-x64 also returns 200. The installed app was not switched to that build, so loopback gateway behavior of the downloaded installer is not claimed here.

What should OpenCodex do?

• Recognize the current Private Inference distribution: the cursor-local update channel and downloads.cursor.com/local-mode/... installer, not only an install whose nameLong is already "Cursor Private Inference".
• On the Cursor integration page, when only regular Cursor is detected and that channel advertises an installer, show the installer URL (or "open the Cursor Private Inference download") instead of only "not found".
• Keep the existing read-only boundary: do not download, install, or write Cursor settings from OpenCodex.
• After that build is installed, keep the current gateway copy values and the installed-bundle effort table. The static mirror remains the fallback when no bundle can be read.
• Do not add a public-tunnel path.

Example usage or interface

Integrations → Cursor, regular Cursor 3.21.18 only:

• Before: "Cursor Private Inference — not found. Only regular Cursor was found; without a public tunnel it cannot reach the loopback proxy."
• After: "Cursor Private Inference is a separate local-mode build. Cursor 3.21.18 advertises a user installer: . Install it, then paste the Base URL and API key below into Settings → Models → Gateway."

Alternatives or workarounds

Install the local-mode build by hand from the update manifest above, then paste the two gateway values. That is the whole user workaround; the dashboard does not surface the URL.

#974 tracked the older localMode blocker and was closed not_planned on 2026-08-27. This is the follow-up now that Cursor publishes the local-mode installer for the same stable version. ocx-cursor / a public tunnel is not the requested path.

Additional context

• OpenCodex: @bitkyc08/opencodex 2.63.0.
• OS: Windows 11 25H2, build 26200.
• Cursor install read: version 3.21.18, commit c4730f7d93d787d9ab120af715999f0345ee5bc0, nameLong "Cursor". The local-mode manifest names commit c4730f7d93d787d9ab120af715999f0345ee5bc5.
• No request from this regular install has reached the proxy, which matches the current "regular build cannot use loopback" behavior.

Checks

• I searched existing issues and documentation.
• This request describes a concrete OpenCodex workflow rather than merely naming a desired technology.
• I removed secrets and personal data.

AI-Context: Session-Ref: ocx-cursor-pi · Device: desktop · User-Role: owner · Endpoint: github · Workspace: lidge-jun/opencodex · Quota-Band: unknown
AI-Execution: Provider: xai · Router: n/a · Route-Alias: n/a · Model-Source: unknown · Role: implementer · Environment: local
AI-Tool: other:codex · Model: grok-4.7 · Mode: default · Session: ocx-cursor-pi · Date: 2026-09-23