Repository navigation
bug(cursor): system prompt says “openpi MCP tools” while advertised names are read/rg/bash [under investigation] #513
Description
Status
Under investigation. Isolated reliability work against v0.8.1 (a3edee28). Not a formal Benchmark.
Impact
CURSOR_PI_TOOLS_SYSTEM_PROMPT (extensions/ai-providers/cursor/tool-bridge.ts) tells the model to use “the provided openpi MCP tools” and not Cursor-native tools. Advertised Pi tool names remain read / rg / bash. On some cursor-grok-4.6-high-fast class-A runs the model completed 23–24 successful read+rg calls, then looped claiming it had used Cursor-native / non-mcp_openpi_* wrappers and never wrote the acceptor file (harness timeout). Distinct from connection timeout, cancel, and native-exec rejection.
Evidence
- Class A,
cursor-grok-4.6-high-fast, attempts 01 and 04 of 5: timeout after many successful Pi tools; no ACCEPT_A. - Same cell on
cursor-grok-4.6-high: 5/5 correct. - Class C on high-fast: 5/5 with a recorded
native_rejectionthen Pi recovery (PR fix(cursor): recover from native tool requests without native execution #484 path works when a native request actually occurs). - Prompt is not snapshotted in tests today.
Unblock
Need a prompt-wording repro that does not collapse into “the model was slow,” then a minimal prompt change that names the advertised tool IDs, plus ≥10 before/after on the same A task+acceptor. Do not disable tools or swallow the loop.
Applicability
OpenPI Cursor provider, v0.8.1. Related: #234 / PR #484 (native exec rejection) — this issue is leftover identity/loop behavior after tools already succeeded.
Activity
ooiuuii commentedon Sep 11, 2026
I would like to help with the narrow tool-name wording issue. On current
main@5bf2fe29e52801d79826c2eb573be403f53285e5, the bridge still refers to "provided openpi MCP tools", whilebuildCursorToolsadvertises the original tool names. This confirms the wording to investigate, not that wording has been proven to cause the reported model loop.Could you link the exact public class-A task and acceptor, together with the frozen run configuration used for the report? The issue asks for at least 10 before/after trials on the same A task, so substituting a newly invented prompt would not be a valid reproduction of that evidence.
My proposed scope is a minimal clarification of advertised tool identities only after reproducing the behavior, plus a prompt contract test and the paired run receipts. No tool disabling, renamed execution API, or swallowed failures. I have not changed the provider prompt or claimed this bug fixed; a passing string test alone would not satisfy the requested behavior proof.
outlier27-cell commentedon Oct 7, 2026
我已核对当前 origin/main、开放 PR 和 Issue，确认 #513 没有等价开放 PR。最小证据是 Cursor request_context 实际广告 Pi 工具名为 read/rg/bash，但系统提示词称其为 openpi MCP tools；Issue 中记录的 class-A loop 与该命名不一致相符。
本分支将提示词改为明确引用 request context 中实际广告的 Pi tool names，并明确禁止模型发明 MCP 前缀；执行边界和 Pi permission ownership 不变。
验证：
分支提交：05988ef