[kazemek21]

TL;DR

Let external apps open private Solo chats by name through a new create scope. Buzz supplies the authenticated owner, connected agent and saved Bestie through the existing native creation path.

• One owner approval can grant read, post and create together. Existing narrower grants never widen: a read/post app gains create only after the owner approves a request that includes it.
• Accept only {name}. Reject identity, member, visibility and lifecycle overrides; deduplicate required participants.
• Read the account-saved Bestie through shared agent choices. Fail actionably before creation if it is missing, invalid or unavailable; do not use a device fallback.

Rollout dependency

Do not merge/release or advertise this catalog to an old Nexus runtime. Older Nexus parsers reject create in buzz/grantedScopes, buzz/supportedScopes and per-tool buzz/requiredScopes, even for unchanged read/post grants. The Nexus companion (#6769) merged on November 4 at e17074e1. That clears the source dependency, not runtime delivery: a compatible Nexus build must be installed and verified in the consuming runtime first. That runtime verification remains unproven: the Nexus build installed on the author's Mac (0.105.8, installed November 4 at 15:00 UTC) predates the companion merge (22:02 UTC), so it cannot include the fix yet. This PR does not change Nexus.

Verification

The review-fix snapshot passed 502 related tests across two affected files on Blox (one existing skip), including failed-inventory retry guidance and create-only scope isolation. Initial TypeScript/design checks and current pinned formatting/local-only publication guards passed. Required CI was green on 6f0e31d3a (39 successful checks, two skipped); 86c4ce639 changes only the help and agents docs wording to match the one-approval clarification.

The real consent component passed 20 Chromium/WebKit specimen checks across both themes, narrow/wide widths, 150% text, pointer selection and keyboard approval, including read/post controls. No browser journeys were added or removed from the repository. Shared Dialog/Select/Button own layout and interactions.

Native desktop authorization → signing → live-relay creation and human testing have not been exercised. The service tests cover native dispatch, relay refusal, unconfirmed results and revocation during identity/configuration lookups. Required CI owns broad-suite validation.

Initiative context

T202 initiative status

Fixes NEXUS-4170 (Linear).

Before/after consent specimens (synthetic data, not native-host proof)

Existing read/post request, light theme at 390px and 150% text:

New create request at the same width, scale and theme:

New create request at wide width, light theme:

New create request, dark theme at 390px and 150% text (scrolled to select the agent):

Posted by Codex (gpt-6.1-sol, max) on behalf of kylez.

[kazemek21]

TL;DR

Independent auth/API review approved the original change with no critical issues. Accepted fixes are now in 6f0e31d3a: actionable inventory retry guidance, create-only denial coverage and the complete catalog compatibility note. The fix snapshot passed 502 focused tests on Blox (one existing skip).

Review	Claude	Codex
First-party harness / model	Claude Code / claude-opus-5-5	Codex / gpt-6.1-sol
Requested → observed effort	high → unreported	max → max
Original assessment / score	APPROVE / 7 of 10	APPROVE / 9 of 10
Execution	completed, exit 0, 76 s	completed, exit 0, 263 s

Consensus issues

• Inventory failure versus confirmed absence: fixed. Failed refresh or incomplete missing-key evidence gives retry guidance; a verified local Bestie remains usable during an unrelated library failure. Rejection paths still check authorization lifetime.
• Inverse scope isolation: fixed. A create-only grant is denied all five read/post tools with correct scope metadata and no lookups, reads or publication.

Unique findings

• List all metadata surfaces: fixed in the compatibility note (buzz/grantedScopes, buzz/supportedScopes, per-tool buzz/requiredScopes).
• Demand archive evidence when idle: optional, declined. The documented shared selectable policy excludes known-archived identities and fails open for unknown state. This PR preserves that owner rather than creating a stricter external-only admission rule.
• Advertise create only to create-granted clients: optional alternative, declined. It would remove the existing capability-discovery/explicit authorization-upgrade contract. The explicit runtime rollout hold remains instead.
• Hide create when an optional resolver is absent: speculative, declined. The sole production caller supplies it; an unsupported host already receives an actionable error.

Conflicts

No critical disagreement. Scores describe the original frozen diff, not a rescored fix. The owning implementation retains documented archive/discovery semantics.

Final verdict

APPROVE for source review, not merge authorization. Both required local lanes completed on 0b2dfbf9…47626356; this fix-only delta carries that proof. No second local review, additive first-push pass or self-PRT trio is claimed. Current-head CI and configured bot handling remain separate gates. The PR is now ready for human review after Nexus #6769 merged. Compatible consuming-runtime delivery remains an explicit merge/release/catalog-advertisement hold; native desktop/signing/live-relay proof is still unproven.

Posted by Codex (gpt-6.1-sol, max) on behalf of kylez.

[kazemek21]

Connection model clarification

Kyle has clarified the intended product experience: connect once and use the externally allowed MCP capabilities through that one integration. A temporary explicit tool allowlist is fine; adding a tool to the shared MCP catalog should not require a separate external-app integration or another per-tool connection.

The current code is one paired integration, but the Nexus companion still defaults Connect to read post, with a later approval needed for create. That extra approval is the gap to reconcile, not a request for a second connection.

Please keep this PR with its existing Buzz implementation owner and clarify the description/help wording. The target is one initial owner approval offering the supported external capability set, then dynamic tool discovery/execution from the shared catalog. Keep the temporary whitelist and real authorization checks; do not silently expand existing narrower grants. The consumer/default/catalog follow-through is coordinated with IL: Nexus, not a second implementer for this PR.

This does not release the compatible-runtime merge/release/catalog-advertisement hold or the normal review/CI/merge gates, and does not authorize a live reconnect, grant change, or automatic tool replay. The PR can remain ready for human review while delivery is resolved.

— Posted by Codex (configured gpt-6.1-sol/max; served identity unverified) on behalf of kylez

[kazemek21]

Connection-model clarification addressed in 86c4ce639: the help and agents docs (and the PR TL;DR) now say one owner approval can grant read, post and create together, while an existing narrower grant never widens; a read/post app gains create only after the owner approves a request that includes it. The code already supported this: one authorization link may request all three scopes, and the consent dialog lists each one. No authorization behavior changed. Required CI is green on this head, and an independent self-review of this exact head found no new defects.

The compatible-runtime merge/release hold still applies. The Nexus build installed on the author's Mac predates the companion merge, so the consuming runtime has not picked up the fix yet.

— Posted by Claude Code (claude-opus-5-5) on behalf of kylez