Problem
The desktop drops any agent-flagged identity that is not in the local managed-agents list before the relay-directory eligibility logic ever runs:
useMentions.ts calls isAgentIdentityInManagedList(candidate, managedAgentPubkeys) as a pre-emptive gate in addCandidate, ahead of shouldHideAgentFromMentions. The directory-based path (mentionableAgentPubkeys built from kind:10100 RelayAgents with respond_to: anyone/allowlist + shared channels) is therefore unreachable for agents the viewer doesn't locally manage — including the "Invocable => always show" and member/Option-B rules that shouldHideAgentFromMentions explicitly implements.MembersSidebar.tsx applies the same managed-list-only gate to add-member search candidates, so a shared agent can't be added to a channel by anyone but the desktop that owns it.
Net effect: a relay-hosted shared agent (kind:0 with NIP-OA auth tag + kind:10100 profile, respond_to: anyone, member of the channel) responds fine when p-tagged, but no other member can @-complete it from the composer or add it to channels — it's structurally invisible as an agent to everyone except its owning device. (Found running a headless shared agent on a self-hosted multi-tenant relay; the only workaround is stripping the agent's auth tag/10100 so it masquerades as a human member.)
Expected
shouldHideAgentFromMentions is already the correct, complete policy (invocable → show; non-member non-invocable → hide; member + directory-excluded → hide; member + unknown → show). It should be the single authority in the composer, and the add-member gate should accept relay-directory agents that would respond to the current user.
🤖 Generated with Claude Code
Problem
The desktop drops any agent-flagged identity that is not in the local managed-agents list before the relay-directory eligibility logic ever runs:
useMentions.tscallsisAgentIdentityInManagedList(candidate, managedAgentPubkeys)as a pre-emptive gate inaddCandidate, ahead ofshouldHideAgentFromMentions. The directory-based path (mentionableAgentPubkeysbuilt from kind:10100RelayAgents withrespond_to: anyone/allowlist + shared channels) is therefore unreachable for agents the viewer doesn't locally manage — including the "Invocable => always show" and member/Option-B rules thatshouldHideAgentFromMentionsexplicitly implements.MembersSidebar.tsxapplies the same managed-list-only gate to add-member search candidates, so a shared agent can't be added to a channel by anyone but the desktop that owns it.Net effect: a relay-hosted shared agent (kind:0 with NIP-OA auth tag + kind:10100 profile,
respond_to: anyone, member of the channel) responds fine when p-tagged, but no other member can @-complete it from the composer or add it to channels — it's structurally invisible as an agent to everyone except its owning device. (Found running a headless shared agent on a self-hosted multi-tenant relay; the only workaround is stripping the agent's auth tag/10100 so it masquerades as a human member.)Expected
shouldHideAgentFromMentionsis already the correct, complete policy (invocable → show; non-member non-invocable → hide; member + directory-excluded → hide; member + unknown → show). It should be the single authority in the composer, and the add-member gate should accept relay-directory agents that would respond to the current user.🤖 Generated with Claude Code