Activity

1. josephwasily commented on Sep 2, 2026

   

   josephwasily

   on Sep 2, 2026

   Author

   More actions

   Update & Workaround / Resolution Found

   After deeper investigation into the codebase (desktop/src-tauri/src/nostr_convert/agent_directory.rs and agentAutocompleteEligibility.ts), we identified why remote server-hosted agents disappear from the @ mentions picker and how to properly configure them:

   1. The Keyring Error when Adding to Local managed-agents.json

   Attempting to manually register a remote agent into the client-side %APPDATA%/.../agents/managed-agents.json causes Buzz Desktop to treat the agent as a local desktop child process. When a user selects the mention chip, Desktop tries to spawn a local daemon and queries the OS Keyring (Windows Credential Manager) for its nsec private key, failing with:
   agent <pubkey> has no private key available — the OS keyring may be unreachable.

   2. The Native Remote Solution: Publishing Kind 10100 & Kind 30177

   Buzz Desktop (0.5.12+) checks relay_agents_from_directory_events and relayAgentCanRespondInChannel using two Nostr protocol events:

   1. kind: 10100 (Agent Directory Profile): Authored and signed by the agent's pubkey, containing:

      {
        "name": "Captain",
        "display_name": "Captain",
        "channel_add_policy": "open",
        "respond_to": "anyone",
        "respond_to_allowlist": [],
        "channels": ["<channel-uuid>", ...],
        "channel_ids": ["<channel-uuid>", ...]
      }

   2. kind: 30177 (Managed Agent Directory Coordinate): Specifying agent parameter coordinates (name, parallelism, respond_to).

   Once kind: 10100 and kind: 30177 are published to the relay:

   • Buzz Desktop instantly indexes the agent as an active, verified relay agent.
   • Native @ mention autocomplete is immediately restored across all channels for all users without requiring any local runner on individual laptops.

   We recommend having buzz-acp automatically reconcile and publish its complete kind: 10100 directory profile upon startup after channel discovery.
2. jinwoo-pa commented on Oct 10, 2026

   

   jinwoo-pa

   on Oct 10, 2026 – with ChatGPT Codex Connector

   More actions

   Additional reproduction on Buzz Desktop for Windows v0.5.28:

   • A remote agent is a channel member with role bot. Its profile resolves by both pubkey and display name, and it is not archived.
   • The same owner account can select and mention this agent in the iPhone app; the agent receives and responds to those mentions.
   • On Windows, this agent initially appeared in the thread composer’s @ picker and responded during a short collaboration test. Later, selecting it produced: “Could not authorize a mentioned agent. Check its access and channel membership, then retry or remove the mention.”
   • After restarting Desktop, the agent remained in the channel member list but disappeared from the thread composer’s @ search. Other agents in the same channel are still searchable and mentionable on Windows. Restarting did not restore this agent to the picker.

   Expected: An eligible channel agent that can be mentioned from iPhone should also appear in the Windows Desktop picker.

   This resembles #7222, but the initial success, subsequent authorization warning, and single-agent impact may indicate an additional state or authorization condition. I have not verified this agent’s kind:10100 or kind:30177 directory records, so I cannot confirm whether the workaround in the existing comment applies.
3. jinwoo-pa commented on Oct 10, 2026

   

   jinwoo-pa

   on Oct 10, 2026 – with ChatGPT Codex Connector

   More actions

   Follow-up to my earlier report (#issuecomment-6101990330) on Windows Buzz Desktop v0.5.28:

   After leaving the app overnight and opening Windows Buzz again the next morning, the previously missing remote agent reappeared in the channel thread's @-mention picker.

   However, selecting the agent immediately triggers the same authorization warning before I send any message:

   Could not authorize a mentioned agent. Check its access and channel membership, then retry or remove the mention.

   So the picker visibility issue is intermittent, but the authorization failure persists at mention-selection time. The agent was previously confirmed as an online channel bot/relay member and can be mentioned and respond from iPhone. Other remote agents remain mentionable on Windows.

   This may help distinguish mention candidate discovery/cache refresh from the subsequent authorization check. I have not determined whether the rejection occurs locally or at the Relay, and have not changed any credentials, membership, or service settings.
4. jinwoo-pa commented on Oct 11, 2026

   

   jinwoo-pa

   on Oct 11, 2026 – with ChatGPT Codex Connector

   More actions

   Additional finding (2026-10-11): affected remote agent appears as People, not Agent, in Windows "Add people and agents"

   Following my earlier Windows v0.5.28 reports, I found a more specific UI inconsistency affecting only the remote server-hosted Codex agent named 검증 (verification).

   Observed behavior

   • In the Windows Desktop "Add people and agents" picker for another channel, four other server-hosted Codex teammates are labeled Agent, while 검증 alone appears under/as People.
   • Adding 검증 to that new test channel does not make it respond there, on either Windows or iPhone.
   • By contrast, 검증 still responds normally to @mentions from iPhone in its original collaboration channel.
   • In the original channel on Windows, its @mention autocomplete visibility has been intermittent; when selectable, it has also produced the pre-send error: "Could not authorize a mentioned agent. Check its access and channel membership, then retry or remove the mention."
   • A read-only server check confirmed that 검증 has channel role bot in the original channel, as do the other compared teammates. Its local manifest pubkey matched the relay profile/channel roster. A profile lookup succeeds, and the checked archive snapshot did not include this agent.

   Read-only code investigation by our server-side team (source checkout 8af2d91f3, dated 2026-10-02; not yet verified identical to the installed Windows Desktop build):

   • The add-member search row's Agent/People label follows user.isAgent: desktop/src/features/channels/ui/AddMemberSearchResultRow.tsx.
   • MembersSidebar.tsx combines kind:0 user search, list_relay_agents, and list_managed_agents; matching pubkeys are merged, with isAgent combined by OR.
   • The kind:0 user-search path uses validated NIP-OA ownership/auth tags to set is_agent: desktop/src-tauri/src/nostr_convert/user_search.rs.
   • Relay-agent discovery involves agent directory/coordinate events and channel membership, whereas mention eligibility independently checks response policy, allowlists/owner, and channel sharing. Thus a bot channel role alone does not guarantee an Agent label in this picker, and the mention-authorization failure is not yet proven to have the same root cause.
   • Possible explanation from this code: if the agent is present through the user-profile search as isAgent=false, but absent from the resolved relay/local agent catalogs, it can appear as People. This is a hypothesis, not a confirmed missing event or bad registration.

   Not yet verified: the affected and working agents' latest kind:0 NIP-OA auth tags, kind:10100 / kind:30177 events, the installed Windows client's actual list_relay_agents output and isAgent state, or whether the new channel is in the agent's effective listening/response scope. The read-only relay event request was rejected with auth-required. The investigated source checkout may differ from the installed v0.5.28 UI.

   Questions for maintainers

   1. Could an agent whose existing channel membership is bot be shown as People because NIP-OA verification or relay-agent catalog lookup fails or is stale?
   2. Could this same identity/discovery inconsistency contribute to the pre-send mention authorization error, or are the two code paths independent?
   3. Which safe, read-only Windows Desktop diagnostics would reveal the underlying isAgent, list_relay_agents, and mention-eligibility decisions?

   We have not changed agent registrations, credentials, ACLs, channel permissions, or services. We would prefer to preserve the agent's working original channel while narrowing down the cause.
5. jinwoo-pa commented on Oct 11, 2026

   

   jinwoo-pa

   on Oct 11, 2026

   More actions

   Screenshot evidence: One remote Codex agent is classified differently

   The attached screenshot shows the Channel members → Add people and agents search results in Buzz Desktop for Windows v0.5.28.

   All five remote Codex agents appear in the same search results, but they are classified differently:

   • 코덱스 검증 (Verification): No agent badge — appears as a regular person.
   • 코덱스 리드 (Lead): agent badge displayed.
   • 코덱스 리서치 (Research): agent badge displayed.
   • 코덱스 설계 (Design): agent badge displayed.
   • 코덱스 코드·기술 (Code/Technical): agent badge displayed.

   The affected Verification agent is registered with the bot role in its original collaboration channel and responds successfully to mentions from the iPhone app in that channel.

   However, Windows Desktop intermittently fails to recognize or authorize this agent for mentions. It also does not respond in a newly added test channel on either Windows or iPhone.

   This screenshot provides visible evidence of an agent-classification inconsistency. The exact relationship between the missing agent badge, the mention authorization error, and the new-channel response failure remains unconfirmed.

   Please see my earlier investigation comment for the relevant source-code paths and diagnostic findings.