The workflow
A composer customization such as Prompt Improver needs to start an invisible BB agent using everything currently present in the prompt box. When the user includes screenshot attachments, the plugin must forward those images together with the text and structured mentions so the helper agent sees the same context the user composed.
What happens today
On bb core main at 1654d0f00, the public composer API exposes the current plain text while the read-only composer view exposes only an attachment count. The host keeps the actual screenshot/file paths and structured mentions in private draft state.
A plugin can therefore preserve text-only behavior, but it cannot reconstruct or forward the complete prompt. Sending only the text silently drops screenshots and files; an attachment count is not enough to recover them.
A focused regression at the real host adapter confirmed that no structured composer-input reader existed before the proposed change.
What you would expect
Provide an additive experimental plugin API that snapshots the same structured PromptInput[] the active composer would submit at call time. It should:
- include normalized text and structured mention ranges;
- include independently attached screenshots and files using their host-managed paths;
- return data detached from live draft state;
- avoid mutating, clearing, focusing, or submitting the composer;
- work through the official plugin frontend test harness;
- preserve existing text-only composer behavior and compatibility.
This enables Prompt Improver and similar plugins to forward the snapshot unchanged to threads.spawn({ input }) after the core API ships.
Context and alternatives
Flattening attachments into text or querying private host state would be incomplete and brittle. A host-owned snapshot at the existing composer boundary reuses BB's current draft-to-input conversion policy and keeps attachment semantics centralized.
No SDK version or protocol change is required beyond the additive API in the existing unreleased 0.4.9 integration target on main.
Related implementation: #1977
Investigation thread: thr_bwikffmsvp
AGENT GENERATED: by GPT-5.6-Sol
The workflow
A composer customization such as Prompt Improver needs to start an invisible BB agent using everything currently present in the prompt box. When the user includes screenshot attachments, the plugin must forward those images together with the text and structured mentions so the helper agent sees the same context the user composed.
What happens today
On bb core main at
1654d0f00, the public composer API exposes the current plain text while the read-only composer view exposes only an attachment count. The host keeps the actual screenshot/file paths and structured mentions in private draft state.A plugin can therefore preserve text-only behavior, but it cannot reconstruct or forward the complete prompt. Sending only the text silently drops screenshots and files; an attachment count is not enough to recover them.
A focused regression at the real host adapter confirmed that no structured composer-input reader existed before the proposed change.
What you would expect
Provide an additive experimental plugin API that snapshots the same structured
PromptInput[]the active composer would submit at call time. It should:This enables Prompt Improver and similar plugins to forward the snapshot unchanged to
threads.spawn({ input })after the core API ships.Context and alternatives
Flattening attachments into text or querying private host state would be incomplete and brittle. A host-owned snapshot at the existing composer boundary reuses BB's current draft-to-input conversion policy and keeps attachment semantics centralized.
No SDK version or protocol change is required beyond the additive API in the existing unreleased 0.4.9 integration target on main.
Related implementation: #1977
Investigation thread:
thr_bwikffmsvp