feat(tools): per-sender tool capability tiers via toolsBySender#66933
Conversation
Greptile SummaryThis PR introduces per-sender tool capability tiers by adding Confidence Score: 5/5Safe to merge — implementation is correct, null-safe, and properly integrated into both tool pipelines. All previously flagged P0/P1 concerns appear addressed in the current HEAD: No files require special attention. Reviews (4): Last reviewed commit: "fix(tools): address Codex P2 review find..." | Re-trigger Greptile |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: be4941d698
ℹ️ About Codex in GitHub
Codex has been enabled to automatically 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 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 5e5f505c74
ℹ️ About Codex in GitHub
Codex has been enabled to automatically 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 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: e1efe5c8f0
ℹ️ About Codex in GitHub
Codex has been enabled to automatically 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 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
f1e4e75 to
dcd3e69
Compare
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: dcd3e69ee8
ℹ️ About Codex in GitHub
Codex has been enabled to automatically 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 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
|
@greptile-apps review please |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: f9c776aa75
ℹ️ About Codex in GitHub
Codex has been enabled to automatically 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 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
88652ca to
f2d2838
Compare
|
@greptile-apps review please |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 34a70ee22d
ℹ️ About Codex in GitHub
Codex has been enabled to automatically 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 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
|
@greptileai review |
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 9c259c975f
ℹ️ About Codex in GitHub
Codex has been enabled to automatically 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 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
Review statusGreptile (latest): 5/5 — Safe to merge. All previously flagged P0/P1 concerns addressed in current HEAD ( Codex (latest re-review): 8 findings — verified against current code:
Codex's stateless re-runs appear to be re-flagging issues from the cumulative PR diff without retaining context that they were addressed in subsequent commits. Greptile's in-place comment update reflects the current state more reliably. Resolving threads as they're either fixed or non-blocking. Ready for maintainer review. |
|
Codex review: needs changes before merge. Summary Reproducibility: yes. for the review finding via source inspection: current main sends untyped keys through the legacy id fallback, while PR head classifies Real behavior proof Next step before merge Security Review findings
Review detailsBest possible solution: Keep the PR open, preserve legacy sender-id matching for malformed Do we have a high-confidence way to reproduce the issue? Yes for the review finding via source inspection: current main sends untyped keys through the legacy id fallback, while PR head classifies Is this the best way to solve the issue? No. The overall direction is plausible, but the current parser is not the safest implementation until malformed Full review comments:
Overall correctness: patch is incorrect Security concerns:
Acceptance criteria:
What I checked:
Likely related people:
Remaining risk / open question:
Codex review notes: model gpt-5.5, reasoning high; reviewed against f95b38baeced. |
|
Codex review: needs maintainer review before merge. What this changes: This PR adds global and per-agent Maintainer follow-up before merge: This is an active implementation PR for a security-sensitive tool-capability boundary, so the next step is maintainer review of product/security semantics plus requested tests and rebase, not an automated replacement PR. Review detailsBest possible solution: Keep the PR open for maintainer review. If the direction is accepted, rebase onto current main, keep the explicit Acceptance criteria:
What I checked:
Likely related people:
Remaining risk / open question:
Codex review notes: model gpt-5.5, reasoning high; reviewed against acae48b790fa. |
9c259c9 to
209498d
Compare
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: e507ed2c3b
ℹ️ 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".
| }; | ||
|
|
||
| export const TOOLS_BY_SENDER_KEY_TYPES = ["id", "e164", "username", "name"] as const; | ||
| export const TOOLS_BY_SENDER_KEY_TYPES = ["channel", "id", "e164", "username", "name"] as const; |
There was a problem hiding this comment.
Preserve legacy sender IDs beginning with
channel:
Adding "channel" to TOOLS_BY_SENDER_KEY_TYPES makes keys like "channel:alice" enter the typed-parser path, but they are malformed for the new channel:<channelId>:<senderId> format and get dropped (no legacy fallback). Before this commit, the same untyped key was treated as a legacy sender-id key and matched senderId="channel:alice"; after upgrade, that policy silently stops applying. This is a backward-compatibility regression for existing configs that use sender IDs starting with channel: and can unintentionally remove sender-specific restrictions unless operators rewrite them to id:channel:alice.
Useful? React with 👍 / 👎.
ae75adf to
a083536
Compare
Co-authored-by: Jerran C. <[email protected]>
a083536 to
62a5575
Compare
|
Verification for rewritten implementation:
Known gap: the live smoke used a disposable ignored script under |
Co-authored-by: Peter Steinberger <[email protected]> # Conflicts: # docs/.generated/config-baseline.sha256
Co-authored-by: Peter Steinberger <[email protected]> # Conflicts: # docs/.generated/config-baseline.sha256
Co-authored-by: Peter Steinberger <[email protected]>
Co-authored-by: Peter Steinberger <[email protected]>
Co-authored-by: Peter Steinberger <[email protected]>
Co-authored-by: Peter Steinberger <[email protected]>
Co-authored-by: Peter Steinberger <[email protected]>
Co-authored-by: Peter Steinberger <[email protected]>
Co-authored-by: Peter Steinberger <[email protected]>
Co-authored-by: Peter Steinberger <[email protected]>
Summary
tools.toolsBySender(global) andagents.<id>.tools.toolsBySender(per-agent override) config fields that strip tools from the LLM's schema on a per-sender basis — denied capabilities are genuinely invisible to the model for that user, not just blocked at runtimediscord:<snowflake>,telegram:<userId>, etc.) to prevent cross-platform sender ID collisions — works in both the new global policy and existing group-leveltoolsBySenderconfigsmessageProviderthroughGroupToolPolicySenderso alltoolsBySenderlookups are platform-awareMotivation
Right now there's no way to give different users different capability levels. If a friend messages your OpenClaw instance and asks it to run a destructive shell command, OpenClaw will attempt it. The owner should have full access; guests should get a restricted toolset baked into the model's context at the schema level so the LLM doesn't even know those tools exist for them.
Key formats
discord:123456789012345678telegram:987654321<channel>:<senderId>id:<senderId>e164:+15551234567username:bob*Match priority: channel-scoped → id → e164 → username → name →
*Example
openclaw.json{ "tools": { "toolsBySender": { "discord:123456789012345678": {}, "telegram:987654321": {}, "*": { "deny": ["exec", "process", "write", "edit"] } } } }Run
/whoamiin any channel to get your senderId and channel name.Files changed
src/config/types.tools.ts—toolsBySenderfield onToolsConfigandAgentToolsConfigsrc/config/group-policy.ts—messageProvideronGroupToolPolicySender,channelbucket, compound key detectionsrc/agents/sender-tool-policy.ts(new) —resolveGlobalSenderToolPolicy()src/agents/pi-tools.ts— resolve + inject sender policy into the pipeline4 files, ~175 lines net. No breaking changes — all new fields are optional.
Test plan
discord:<my-snowflake>: {}) — all tools available as normaldiscord:<friend-snowflake>: { "deny": ["exec", "process"] }) — exec/process absent from tool schema; model replies it cannot run commands*deny — applies to any sender without an explicit entrytoolsBySenderin config — behaviour unchanged from beforeAI-assisted checklist
pnpm testnot yet run on this machine)