Skip to content

/cursor:status fails when delegate is started via Claude Code background command — wrong job ID surfaced to user #7

@freema

Description

@freema

Summary

When /cursor:delegate is invoked via Claude Code's background command mode (the Command running in background with ID: … flow), the ID surfaced to the user is Claude Code's own background job ID, not the cursor plugin's job ID. As a result /cursor:status <that-id> always fails with No job <id> found for this repository.

The real cursor job ID is buried inside the background output file (e.g. Job \7FfFUyUK5w` started on model `composer-2-fast` (foreground).`), and the user has no obvious way to recover it.

Repro

  1. In Claude Code, run /cursor:delegate <some task> such that the command runs as a Claude Code background command (CC decides to background it).
  2. CC prints something like:
    Command running in background with ID: bo2565uts. Output is being written to: /private/tmp/claude-501/.../tasks/bo2565uts.output. ...
    
  3. Run /cursor:status bo2565uts.
  4. Error:
    Error: Shell command failed for pattern \"!\`node \".../scripts/status.mjs\" -- \"bo2565uts\"\`\": [stderr]
    No job \`bo2565uts\` found for this repository.
    

Root cause (from quick inspection of delegate.mjs / status.mjs)

  • delegate.mjs generates a fresh ID via lib/id.mjs#id() and writes the job under that key (e.g. 7FfFUyUK5w).
  • When CC backgrounds the command, CC's own wrapper ID (bo2565uts) is what's shown to the user — not the cursor job ID. The cursor job ID is only visible inside the output log file.
  • /cursor:status (and presumably /cursor:result, /cursor:cancel) all key off the cursor job ID, so any user-provided ID copied from the CC notification will miss.

Expected behavior

Some of the following would help:

  1. Surface the cursor job ID prominently in delegate.mjs stdout so CC's background notification echoes it (e.g. the first line, before any tool calls), so users copy the right ID.
  2. Accept the CC background ID as an alias — e.g. /cursor:status could look at the output filename pattern (<cc-id>.output) and resolve via the log path stored on the cursor job record.
  3. Detect this case and print a helpful hint when /cursor:status <id> misses: "No job <id> — if you copied this from a Claude Code background notification, run /cursor:status with no args to see the most recent cursor job."

Workaround

Running /cursor:status without an ID lists tracked jobs (including the real one). Then /cursor:status <real-id> or /cursor:result <real-id> works.

Environment

  • Plugin: tomas-cursor/cursor 0.2.0
  • Host: Claude Code on macOS (Darwin 24.5.0)

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions