Automations editor: could not parse prefill from url on open_automation handoff

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Chat-driven Automations setup cannot complete. An agent builds a draft and calls open_automation with prefillWorkflowData. The Automations editor then shows: “could not parse prefill from url”.

This happened on every attempt the same morning (3+), including:

  1. A full draft (cron + Slack read/send + two MCP servers + long instructions)
  2. A compact ASCII-only retry with empty Slack action objects and a much shorter prompt
  3. A second session following the official /automate skill end-to-end (draft table, approval, then open_automation)

Attempt 3 returned tool success (“Opened Glass Automations”). The form still did not receive a usable prefill. The only working path was pasting instructions from a local markdown file into an existing automation.

Related but not the same as Chat Automations setup broken: open_automation prefill never appears (silent empty form). Here the editor explicitly errors that it tried to parse prefill from a URL, even though the current open_automation tool schema says the payload is sent only to the active Glass view and is not put in a URL or browser storage.

Either the schema is wrong, or Glass still round-trips prefill through a URL and the parser fails. Compact retry also failed, so this is not only “prompt too long for a URL”.

Steps to Reproduce

  1. In Agent chat (Agents Window), ask the agent to create a Cursor Automation via /automate.
  2. Approve a draft that includes at least: custom cron trigger (0 9 * * 2,5); gitConfig for a private owner/repo + main; readSlack + slack actions; two plugin MCP actions (authenticated, dashboard-eligible); memoryEnabled true; instructions of several thousand characters.
  3. Confirm readiness. Agent calls open_automation with prefillWorkflowData.
  4. Observe the Automations editor.

Retry variants that also failed:

  • Same flow with a short ASCII-only prompt and empty readSlack: {} / slack: {} (no channel IDs).
  • Same flow after switching Slack send from channel (singular) to also trying readSlack.channels (array). Still no usable prefill.

Expected Behavior

Prefill is delivered to the Glass Automations form without stuffing JSON into a URL. Name, description, cron, tools, repo, and instructions populate. If delivery fails, open_automation returns an error, not success. The in-editor error, if any, names the invalid field rather than “could not parse prefill from url”.

Operating System

MacOS

Version Information

IDE:
Version: 3.17.21
VSCode Version: 1.128.0
Commit: 8f2a112cb2845a97b75fd932ea5c470579ca4060
Date: 2026-08-25T01:05:08.089Z
OS: Darwin arm64 27.0.0

For AI issues: which model did you use?

Grok 4.6 (agent that called open_automation)

For AI issues: add Request ID with privacy disabled

Not captured. Happy to pull one from the next repro if you say where it is logged for Glass Automations / open_automation.

Additional Information

Finish path used: cursor-app-control open_automation (no browser prefill URL constructed by the agent; no cursor:// deeplink). Tool schema on this build still says prefill is not put in a URL. The UI error proves a URL parse path still exists.

Sanitized payload shapes (no secrets, no private names):

Attempt A (URL parse error):
{
“name”: “[redacted]”,
“description”: “[redacted ~160 chars]”,
“workflow”: {
“triggers”: [{ “cron”: { “cron”: “0 9 * * 2,5” } }],
“actions”: [
{ “readSlack”: {} },
{ “slack”: { “channel”: “C…” } },
{ “mcp”: { “server”: { “name”: “[plugin-a]” } } },
{ “mcp”: { “server”: { “name”: “[plugin-b]” } } }
],
“prompts”: [“<~8k char instruction body, some Unicode punctuation>”]
}
}

Attempt B (also URL parse error):
{
“name”: “[redacted]”,
“workflow”: {
“actions”: [
{ “readSlack”: {} },
{ “slack”: {} },
{ “mcp”: { “server”: { “name”: “[plugin-a]” } } },
{ “mcp”: { “server”: { “name”: “[plugin-b]” } } }
],
“agentOptions”: { “skipInstall”: false },
“gitConfig”: { “branch”: “main”, “repo”: “org/private-repo” },
“memoryEnabled”: true,
“prompts”: [“<short ASCII-only stub, well under 2k chars>”],
“triggers”: [{ “cron”: { “cron”: “0 9 * * 2,5” } }]
}
}

Attempt C (/automate skill, tool success, form still unusable):
{
“workflow”: {
“triggers”: [{ “cron”: { “cron”: “0 9 * * 2,5” } }],
“actions”: [
{ “readSlack”: { “channels”: [“C…”, “C…”] } },
{ “slack”: { “channel”: “C…” } },
{ “mcp”: { “server”: { “name”: “[plugin-a]” } } },
{ “mcp”: { “server”: { “name”: “[plugin-b]” } } }
],
“gitConfig”: { “branch”: “main”, “repo”: “org/private-repo” },
“memoryEnabled”: true,
“agentOptions”: { “skipInstall”: false },
“prompts”: [“<~8.8k char instruction body, ASCII>”]
}
}

Notes for parser owners:

  • Compact retry also failed, so this is not only prompt-too-long-for-a-URL.
  • Possible proto mismatch: Slack action channel (singular, per automate skill) vs trigger-style channels (array). Unknown fields are supposedly ignoreUnknownFields true, which should drop them, not fail URL parse.
  • Slack channels involved were private (C…). Triggers on private Slack are documented as unsupported; these were actions (read/send), not a Slack trigger.
  • Timezone cannot be encoded on cron; it was deferred to the editor. Model slug was omitted on the last call to avoid an invalid enum.
  • Product impact: /automate cannot finish. Users must paste long prompts by hand.

Does this stop you from using Cursor

No but it inconveniences the process of creating automations.

This was done through the agents window not the IDE.

Hey @Dave_Shaw

All three attempts share one thing: the workflow.prompts entries were passed as bare strings. Each one needs to be an object like {"prompt": "<your instructions>"}. Re-run the handoff and have the agent format the prompts that way, and the prefill should populate - length and Unicode weren’t the cause.

You’re right on the other two points too: there’s no URL involved on this path, so that wording is misleading, and the tool shouldn’t report success when the payload won’t load. Those aren’t intended behavior - we’ve let the team know and it’s an issue we’re tracking. I’ll post here when there’s an update.