Add plugin entry: companion-chat

[divyesh-puri]

What it adds

Companion Chat opens a fresh thread beside the current bb conversation. The new thread starts in the current project and worktree, lets the user choose any installed provider and model independently, and stays in the originating panel without adding a top-level sidebar entry.

This is a new conversation, not a fork of the source provider session.

Release

• Source: https://github.com/divyesh-puri/bb-plugin-companion-chat.git
• Release: v0.1.1
• Marketplace range: ^0.1.0
• Release commit: 8d7d508981fd44cbf5ca73a8a41ddef83d6f9bca

Validation

• 6 Vitest tests pass
• TypeScript typecheck passes
• bb plugin build passes
• Clean checkout of v0.1.1 installs production dependencies and builds both server and app bundles
• Marketplace schema build passes with 82 entries
• Marketplace liveness validates the Companion Chat Git source and release; the repository-wide command currently exits nonzero on two unrelated existing npm entries, taskboard and usage-tracker, which were unpublished upstream

Security

Companion Chat is a full-trust bb plugin. It uses bb's native thread and composer APIs, requires no credentials, and connects to no external service.

Companion threads use BB's hidden-thread visibility so they remain in the originating panel without adding top-level sidebar entries.

[SawyerHood]

Automated note from a Claude Code agent, posted on behalf of the marketplace maintainer.

Thanks for the submission — we really want to get this in. For the first run of the marketplace we are aiming for a small set of very polished plugins, and we will open it up more broadly soon. Here is what we found reviewing the source at the tag your entry resolves to and installing it from that entry into a dev build of BB 0.40:

This installs and runs cleanly, and the implementation is careful for its size — full zod modelling of NewThreadRequest with .strict() throughout, a pendingCreates promise map so a double-submit cannot spawn two threads (server.ts:148, :195-216), instance-to-source-thread ownership assertion (:155-161), deleted-companion cleanup (:174-176), and tests covering each. Two small things and we will merge it.

1. The entry description does not mention that companion threads are hidden

The entry says only "Opens a fresh companion thread beside your current BB conversation, with independent provider and model selection and the current worktree preselected."

It does not say the thread is created with visibility: "hidden" (server.ts:200-203), so it stays out of the sidebar thread list — nor that closing the panel tab removes the normal way back to that conversation. Your README says both, clearly, and we can see v0.1.1 was written specifically to add that paragraph, so this is a description-freshness gap rather than concealment. Please bring the entry description in line.

To be clear about what is not a problem: hidden spawn is the sanctioned first-party pattern — BB's own built-in side-chat does exactly the same. And permissionMode is the user's own composer choice passed through unmodified (server.ts:96 validates the enum, :200-203 spreads the request and only adds visibility); the plugin has no path that raises it, and the strict schemas stop a client smuggling a visibility override.

2. It silently reverts a visibility change the user made

server.ts:177-182 forces visibility: "hidden" on every panel restore if the thread is not already hidden. If a user deliberately un-hides a companion thread, the plugin undoes that the next time the panel opens, with no notice. Please hide only at creation time and respect a later user change.

One thing worth considering

The built-in side-chat plugin uses the same SideChat icon and occupies adjacent conceptual space. Yours is meaningfully different — a fresh thread with independent provider/model rather than a fork carrying message context, which your README states explicitly — but users may confuse the two, and both show the same glyph. A distinct icon or a more disambiguating displayName would help. Not a blocker.

What we liked

No network calls at all, no commands, no secrets, no agent tools. zod is correctly the only runtime dependency and the --omit=dev build is clean. SideChat is a valid host icon name.

[SawyerHood]

Automated review (Claude Code agent on behalf of the maintainer): requesting changes per the feedback comment above. Ping here when a new version is published and we will re-check.

[divyesh-puri]

Published Companion Chat v0.1.2 and updated this PR.

Both requested changes are addressed:

1. The marketplace description now discloses that companion threads start hidden and stay out of the sidebar unless the user later makes them visible.
2. Restoring a panel no longer re-hides a companion that the user deliberately made visible.

The release also fixes stale cross-provider composer options: unsupported service tiers are removed, model/reasoning fallbacks preserve honest provenance, explicit unavailable selections fail rather than silently changing, and permission modes are checked against provider capabilities and the environment ceiling.

Validation on v0.1.2:

• 10 Vitest tests pass
• TypeScript typecheck passes
• bb plugin build passes
• Marketplace npm run build passes
• Marketplace npm run check passes

[divyesh-puri]

Published Companion Chat v0.1.3: https://github.com/divyesh-puri/bb-plugin-companion-chat/tree/v0.1.3

This fixes companion provider selection when the composer omits executionInputSources.providerId. Verified end-to-end in BB with a Pi main thread and a new Cursor → Grok 4.6 → High → Fast companion: the spawned thread used acp-cursor, retained the selected model and fast tier, and completed the turn successfully.

Validation: 11 tests passed, TypeScript typecheck passed, and bb plugin build passed.