Repository navigation
fix(reach,social): say which Bot is not shared and point to Sharing when a send to a friend's Bot is refused - #286
Conversation
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 406487464f
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| const why = line(reason) | ||
| if (action === 'deny') { | ||
| const grant = /has no grant to that Bot|has not been granted/i.test(why) | ||
| const grant = /has no grant to that Bot|has not been granted|cannot message their Bots/i.test(why) |
There was a problem hiding this comment.
When a user @-mentions a friend's Bot from a group whose admin/sending Bot is not shared with that friend, reach() returns the new sender-specific reason (Chief ... share Chief ... → Sharing). Adding cannot message their Bots here causes mentionReceipt to classify precisely that reason as a legacy grant failure and replace it on the next line with invite that Bot from Bot settings; because the receipt is labelled with the remote Bot's name, the user is again pointed at the wrong Bot and never sees either Chief or Sharing. Preserve the new reason, or render an equivalent sender-specific hint, for this branch.
Useful? React with 👍 / 👎.
|
Maintainer review (2026-10-18 maintenance): Design OK — refusal names the sending Bot and Sharing (the setting that exists), keeps per-Bot grant deny, and tells the model to relay the reason. Tests and changelog look right. Will rebase onto latest main and squash-merge when CI is green. |
…ng Bot and Sharing, the right way round (ThinkFlowLab#273)
a3df8aa to
8f47fb8
Compare
Fixes #273.
A Bot asked to message a friend's Bot it may not reach got a refusal with the direction backwards ("Chief has no grant to that Bot"), and the model then sent the user to a "team/permissions setting" that does not exist.
core/src/host/reach.jsand the social transport: "Chief is not shared with that friend, so it cannot message their Bots. To allow it, share Chief with them in its settings → Sharing."message_friend_bottells the model to relay the reason as written and not point to any other setting.notSentLine,userFacingSendError,mentionReceipt) still recognise the new wording.Ran at tip:
TZ=UTC ARCH_DOCS_BASE=upstream/main npm run verify(green). Docs: social.md, core-host.md, plugin-runtime.md. Changelog fragment added. Nothing deployed.