[Bug]: preview_click and preview_open validation errors don't say what is wrong with the locator or URL#22402

opened14d agobyTtapabratadey

Before submitting

  • I searched existing issues and did not find a duplicate.
  • I included enough detail to reproduce or investigate the problem.

Related, but not the same: #3714 (generic error when a click target is missing) and #19912 (opaque "failed on client" errors).

Area

apps/server

Steps to reproduce

  1. In a desktop thread, let an agent call preview_click on an open tab with:
    json
    1{ "locator": "div:has(> div > p:text-is(\"Hello\")) > button" }
  2. Call preview_open with:
    json
    1{ "url": "about:blank", "open": false }

Expected behavior

Each error states the rule that was broken, so the agent can fix the call in one try. For example:

  • Locator: "locator accepts aria-ref=<ref> or a Playwright role/text selector. Pass CSS (including :has()) in selector." Or say which part of the string was rejected.
  • URL: "Only absolute http(s) URLs or schemeless hosts are allowed. Omit url to open a blank tab." The preview_open schema already says "Omit to open a blank tab".

Actual behavior

The errors give only a length or an internal parse detail:

1Preview automation click received an invalid locator (44 characters).
2Preview automation open failed: Invalid preview URL (parse: https:; input length 11).

The URL error suggests about:blank was treated as a schemeless host and given https:. That is an inference from the message.

In both cases the agent retried with guesses before finding a form that worked.

A related wording problem: when a session owns more than one tab, the "Multiple browser tabs belong to this session. Pass a tabId" error carries the tag PreviewAutomationControlInterruptedError. That tag suggests a control conflict, not a missing argument. I saw it once; I don't have its exact date.

Impact

Minor bug or occasional failure

Version or commit

Observed in T3 Code Nightly 0.0.46 (URL error, 2026-10-09) and 0.1.1 (locator error, 2026-10-17; nightlies 20261016.3203 to 20261017.3272 were installed that day). Not retested on the currently installed 0.1.1-nightly.20261019.3373.

Environment

macOS 26.6.2 (Darwin 25.6), arm64, T3 Code Nightly desktop app, Codex agent.

Logs or stack traces

The quoted page text in the locator is replaced with a word of the same length.

shell
12026-10-17T18:01:03Z preview_click {"tabId":"tab_1_<id>","locator":"div:has(> div > p:text-is(\"Hello\")) > button"}
2 -> Preview automation click received an invalid locator (44 characters).
32026-10-09T00:16:19Z preview_open {"url":"about:blank","open":false}
4 -> Preview automation open failed: Invalid preview URL (parse: https:; input length 11).

Workaround

Use aria-ref=<ref> from the latest preview_snapshot, pass CSS through selector, and omit url for a blank tab.

Synced from GitHub

I'd like to work on this one.

Plan: change the two error messages so each one says which rule was broken, using the wording suggested above. The locator message is built in packages/contracts/src/previewAutomation.ts (received an invalid ${selectorKind} (N characters)). The URL message is built in packages/shared/src/preview.ts / packages/contracts/src/preview.ts. I'll add focused tests that check the new messages.

I'd leave about:blank being parsed as a schemeless host out of this PR, since it's a separate defect. Should I fix that in a follow-up PR, or do you count it as part of this issue?

Triage: the live server-browser MCP call preview_open({"url":"about:blank","open":false}) returned exactly Preview automation open failed: Invalid preview URL (parse: https:; input length 11). Omitting url opened a blank tab. The reported locator on that tab timed out after 15000ms rather than producing the desktop validation error; macOS desktop was not verified. Current main at 70e5e384da still defines the opaque URL and locator error messages. No duplicate found in the open-issue pages checked; pagination was interrupted by a forge connection error before the 90-day cutoff. Leaving open for maintainer review: changing these MCP validation errors falls under the automated triage MCP tool surface hard stop. No implementation changes or PR.

Fresh triage: the live server-browser call preview_open({"url":"about:blank","open":false}) still returns Preview automation open failed: Invalid preview URL (parse: https:; input length 11). Omitting url opens a blank tab. The reported locator times out on the server browser rather than reaching the desktop validation rejection; macOS desktop remains unverified. Checked all 931 open issues and 1,387 open PRs: no duplicate or existing fix PR found. Proceeding with focused validation-message tests and a wording-only fix under the revised triage brief.

Fix opened as #23396. Isolated Linux dev-server MCP and app RPC runs compare 8acbefefc5 with 0a98dfd95c: invalid URLs and malformed locator/selector errors now explain valid forms and recovery; omitting URL still opens a blank tab. Three focused assertions fail before the fix; 53 tests pass after it. Runtime evidence.

The original CSS-in-locator request times out on Linux on both revisions. macOS desktop validation remains unverified. The submitted branch contains the same preview changes on current main.