Bot → friend's Bot send refused with backwards 'no grant to that Bot' reason; model points to a nonexistent permissions setting; held-send flow unreachable #273

Summary

In the basic friend setup (A shares Chief with B), neither Chief can message the other side when asked. The refusal tells the user to change a permission that does not exist. A Bot's send never reaches the hold step, so a normal user never gets to the held-send flow (the in-chat Approve / Always approve / Reject card, Auto-send).

Environment

• FlyBot main ab723ac (after fix(ui): + menu is a popover next to +; one Copy invite entry; 6 digits room hint (#173) #265), core + plugins/social + plugins/tree on @deepseek-ai/dsh@0.2.0-rc.2, Node 24.
• Two fresh installs on one Linux box: A :3090 (owner SelfA1220, @selfa1220.home) and B :3091 (owner SelfB1220, @selfb1220.home). Bot Social https://47-80-69-220.sslip.io.
• Both Chiefs on ark/deepseek-v4-flash (real model).
• A's Chief is shared with B through a per-Bot invite (grant grt_01M56M32HBPKTGVE0G51AM23C4, grantee @chief.selfb1220.home). B joined with its Chief as the talk-through Bot. B's Chief is not shared back (by design, Per-Bot grants leak: accepting a Helper invite exposes the joiner's Chief; face-room Chief shows in Friends' Bots; Manage access wrong/raw #138/Regression of #138: joining a friend's invite still puts the joiner's Chief on the inviter's main list #161).
• Scheduled product self-test, focus A (friend DM), browser run 2026-10-18 12:27–12:31 Asia/Shanghai. Screenshots stayed on the test machine; what they show is written out below.

Repro

1. On B, in B's own Chief chat: Please send a message to SelfA1220's Chief saying hello from my Bot.
2. On A, in A's own Chief chat: Please send a message to my friend SelfB1220 saying hello.

Actual

• B's Chief: "I tried, but it didn't go through: I don't have a grant to message friends' Bots yet — this is a permission setting on your side. You can likely grant it in the team/permissions settings…"
• A's Chief: "no grant to message SelfB1220 (the friend's Bot), so it was blocked…"
• Neither side shows a held message or an approval card.
• B's Settings → Bots → Chief has no such permission. It shows Profile, Model, Working folder, Instructions, Memory, Scheduled tasks, Main Bot, Sharing, More/Duplicate. "Team/permissions settings" does not exist.

What the code says (ab723ac)

• Denying it is by design. core/src/host/reach.js (local → remote): "the sending Bot must have a grant matching that remote". B's Chief has no grant (state.grants is empty on B; joining does not grant the talk-through Bot back, Per-Bot grants leak: accepting a Helper invite exposes the joiner's Chief; face-room Chief shows in Friends' Bots; Manage access wrong/raw #138/Regression of #138: joining a friend's invite still puts the joiner's Chief on the inviter's main list #161), so message_friend_bot gets deny("Chief has no grant to that Bot, so it cannot message friends' Bots"). On A, reach() passes (A's Chief is granted to @chief.selfb1220.home), but the social middleware denies it because A has no Bot of B's in Friends' Bots (… is not a Bot of a friend on Bot Social). That is also expected, since B shared nothing.
• The problem is the user-facing result:
  1. The reason text has the direction backwards. "has no grant to that Bot" reads as if the friend's Bot is missing a permission. In fact the sending Bot has not been shared with that friend.
  2. The tool result gives the model no actionable step, so it makes up a "team/permissions setting". The composer path already maps the same reason to "none of your Bots is invited to this friend. Invite them from Bot settings." (userFacingSendError), but the message_friend_bot / reach reason reaches the model and the user raw.
  3. Nothing in the UI tells B that, for B's Chief to talk to A's Chief, B has to share Chief with SelfA1220 (Sharing → invite, and A has to accept). It is also unclear whether a second invite between two homes that already have a relationship works, or answers relationship_exists (not tested).

Expected

• One short English refusal that names the step and the setting that exists, for example: "Chief isn't shared with SelfA1220, so it can't message their Bots. Share it in Chief's settings → Sharing." The model should relay it rather than guess.
• A short path from that refusal to Sharing, preferably one that works for an existing friend without a new invite round-trip, if that is acceptable under the per-Bot grant design.
• Design check: today a grant to B lets B as a person talk to A's Chief, but B's Bots cannot, and A's Chief cannot answer (see Friend DM: a shared Bot's reply to the grantee is silently denied (grantee's Bot not shared back), never held or delivered #272). If that is intended, the copy above is the fix. If a Bot should be able to message a friend's Bot it already has access to, reach() needs a rule for it. That is a design decision, not done here.

Related: #51 (per-Bot grants), #138/#161, #254 (held replies), #272 (replies to a grantee).