The workflow
I hand a Linear issue to bb from Linear Desktop's "Work on issue" button, using its local-script option. Sometimes I want the agent to start immediately. Often I want to land in a thread with the issue context already in the composer, read it, add a constraint, then hit send. That review step is exactly what Claude Desktop's prefill behavior gives you, and it is the difference between a handoff I trust and one I have to babysit.
The same need shows up for any script that assembles a prompt: a PR-review helper, a "turn this failing test into a thread" wrapper, or a template picker.
What happens today
bb thread spawn requires --prompt:
$ bb thread spawn --project proj_xxx --json
error: required option '--prompt <prompt>' not specified
So every scripted handoff starts a turn immediately. There is no CLI or HTTP way to create a thread whose composer holds an unsent draft, and no way to seed the compose surface's draft before a thread exists.
Adjacent surfaces that do not cover this:
bb thread queue create <threadId> <message> needs a thread that already exists, which means a turn has already started.
useBbNavigate().toCompose({ initialPrompt, focusPrompt }) in the plugin frontend API does exactly the right thing, but it is only reachable from plugin React code running inside the app, not from a script or another application.
- The SPA reads no prompt query parameter, so loading a route in a browser cannot seed a draft either.
What you would expect
Either shape would solve it, and they are not mutually exclusive:
CLI. A flag or a sibling command that creates the thread and leaves the prompt unsent:
bb thread spawn --project proj_x --environment /repo --prompt "..." --no-send
bb thread compose --project proj_x --environment /repo --prompt "..."
--no-send on spawn keeps one code path and reuses every existing execution flag. It should still print the thread id so the caller can bb thread open it.
URL. If the bb:// scheme in #2199 lands, the compose variant is the natural companion, and it is what a URL-only integration needs:
bb://compose?project=proj_x&prompt=<urlencoded>&environment=/path/to/repo
Both should leave the draft editable and unsent, and should not consume tokens until the user submits.
Context and alternatives
Verified on bb 0.39.0, macOS 15.5.
My current workaround is to accept the immediate start: the script spawns with --prompt and I interrupt the agent if the prompt was wrong. That wastes a turn and, with a long Linear prompt template, sometimes sends the agent off in the wrong direction before I can read what it was told.
A worse alternative I ruled out: spawn with a placeholder prompt such as "wait for instructions" and then send the real one. That burns a turn, pollutes the transcript, and the agent frequently starts exploring the repo anyway.
Related: #2199 (no bb:// URL handler). That issue is about reaching bb from another app at all; this one is about landing in an editable draft once you get there.
Happy to prototype --no-send in a fork if you want it, following CONTRIBUTING's issue-first rule.
Checks
AGENT GENERATED: by claude-opus-5
The workflow
I hand a Linear issue to bb from Linear Desktop's "Work on issue" button, using its local-script option. Sometimes I want the agent to start immediately. Often I want to land in a thread with the issue context already in the composer, read it, add a constraint, then hit send. That review step is exactly what Claude Desktop's prefill behavior gives you, and it is the difference between a handoff I trust and one I have to babysit.
The same need shows up for any script that assembles a prompt: a PR-review helper, a "turn this failing test into a thread" wrapper, or a template picker.
What happens today
bb thread spawnrequires--prompt:So every scripted handoff starts a turn immediately. There is no CLI or HTTP way to create a thread whose composer holds an unsent draft, and no way to seed the compose surface's draft before a thread exists.
Adjacent surfaces that do not cover this:
bb thread queue create <threadId> <message>needs a thread that already exists, which means a turn has already started.useBbNavigate().toCompose({ initialPrompt, focusPrompt })in the plugin frontend API does exactly the right thing, but it is only reachable from plugin React code running inside the app, not from a script or another application.What you would expect
Either shape would solve it, and they are not mutually exclusive:
CLI. A flag or a sibling command that creates the thread and leaves the prompt unsent:
--no-sendonspawnkeeps one code path and reuses every existing execution flag. It should still print the thread id so the caller canbb thread openit.URL. If the
bb://scheme in #2199 lands, the compose variant is the natural companion, and it is what a URL-only integration needs:Both should leave the draft editable and unsent, and should not consume tokens until the user submits.
Context and alternatives
Verified on bb 0.39.0, macOS 15.5.
My current workaround is to accept the immediate start: the script spawns with
--promptand I interrupt the agent if the prompt was wrong. That wastes a turn and, with a long Linear prompt template, sometimes sends the agent off in the wrong direction before I can read what it was told.A worse alternative I ruled out: spawn with a placeholder prompt such as "wait for instructions" and then send the real one. That burns a turn, pollutes the transcript, and the agent frequently starts exploring the repo anyway.
Related: #2199 (no
bb://URL handler). That issue is about reaching bb from another app at all; this one is about landing in an editable draft once you get there.Happy to prototype
--no-sendin a fork if you want it, following CONTRIBUTING's issue-first rule.Checks