bug(cursor): Cursor WebFetch interaction query aborts a tool-enabled turn

[JS-banana]

Problem / Observed Behavior

When using a Cursor-backed model with Pi tools enabled (e.g. cursor/cursor-grok-4.6-high), prompt requests requiring web access can trigger a server-side interactionQuery (field 9: webFetchRequestQuery).

In the current provider implementation, receiving any interactionQuery immediately throws an error:

// extensions/ai-providers/cursor/provider.ts:993-996
if (message.message.case === "interactionQuery") {
  throw new Error(
    `Cursor interaction query ${message.message.value.query.case ?? "unknown"} is unavailable ${context.tools?.length ? "outside Pi's interaction lifecycle" : "in chat-only mode"}`,
  );
}

This immediately aborts the active AgentService/Run turn with stopReason: "error", leaving the model no opportunity to recover, use alternative Pi tools, or explain the limitation to the user.

Environment

• Pi: 0.85.1
• OpenPI: npm:@tt-a1i/openpi@0.8.1
  • Verified: installed extensions/ai-providers/cursor/{provider.ts,proto.ts,tool-bridge.ts} match upstream openpi@0d17f4577fe31315fe6c95370d251bdb4e2413cf byte-for-byte.
• Provider & Model: cursor / cursor-grok-4.6-high

Repro Steps

In a clean session with only Pi's built-in read tool enabled (no bash, no web-fetch skill/tools):

pi --provider cursor --model cursor-grok-4.6-high \
   --tools read \
   --no-skills --no-prompt-templates --no-context-files \
   "请实际访问 https://example.com/ 并返回网页标题，不允许根据记忆回答"

(Note: The reproduction explicitly enables only the read tool, deliberately excluding web fetchers and bash to verify the failure path when native web fetch is attempted.)

Actual Error

Error: Cursor interaction query webFetchRequestQuery is unavailable outside Pi's interaction lifecycle

The CLI turn ends with assistant status error.

Relationship to #234 and #484

• Related to feat(ai-providers): add Google Antigravity and Cursor OAuth providers #234: feat(ai-providers): add Google Antigravity and Cursor OAuth providers #234 tracks initial provider inclusion, where Cursor originally had a coarse chat-only fail-closed boundary.
• Distinction from fix(cursor): recover from native tool requests without native execution #484:
  • PR fix(cursor): recover from native tool requests without native execution #484 (commit e4c2bf4e32b4) resolved the earlier preview error Error: Cursor-native tools are unavailable; use the advertised Pi MCP tools by ignoring non-authoritative InteractionUpdate previews, and added bounded in-band UNIMPLEMENTED rejection for native exec requests (ExecServerMessage, up to 3 times).
  • However, PR fix(cursor): recover from native tool requests without native execution #484 touched only tool preview and native exec frames. It did not cover interactionQuery.
  • extensions/ai-providers/cursor/proto.ts currently lacks AgentClientMessage.interactionResponse (field 6), leaving direct throw as the only coded path upon receiving interactionQuery.

Expected Behavior & Invariants

1. Pi-native ownership remains non-negotiable:
   Cursor-managed cloud fetching must not be approved. Sending an approved response would allow Cursor servers to fetch external URLs in the cloud, bypassing Pi's permission lifecycle, network controls, and audit trails.
2. Turn continuation:
   Rather than hard-throwing and crashing the entire turn, the provider should ideally signal protocol-level rejection so the model retains the turn to either adapt or explain the limitation gracefully.
3. Proposed exploration & boundaries:
   • Define interactionResponse (field 6) and WebFetchRequestResponse.rejected in proto.ts to respond in band.
   • Enforce a bounded rejection limit (similar to MAX_NATIVE_EXEC_REJECTIONS) against repeated query loops.
   • Non-goal / Explicit unknown: In-band rejection is a candidate mitigation to prevent hard crashes. Because model behavior following rejection is subject to Cursor server-side logic, we do not promise or assume that the model will automatically fall back to advertised Pi MCP tools.

[JS-banana]

认领