3 replies

question about toolsBySender + subagent tool inheritance

Version: 2026.2.22-2 (npm install, Linux WSL2)
Setup:
A Discord group channel has this config:

"toolsBySender": {
  "*": { "deny": ["edit", "write", "exec", "process"] },
  "id:<owner_user_id>": { "allow": ["*"] },
  "id:<bot_user_id>": { "allow": ["*"] }
}

"toolsBySender": {
  "*": { "deny": ["edit", "write", "exec", "process"] },
  "id:<owner_user_id>": { "allow": ["*"] },
  "id:<bot_user_id>": { "allow": ["*"] }
}

The owner's user ID and the bot's user ID both have

allow: ["*"]

allow: ["*"]

to override the wildcard deny.
Problem:
When the bot spawns a subagent (via

sessions_spawn

sessions_spawn

) from that group channel session, the subagent cannot use
exec
exec
. It's not in its available toolset. The subagent tried falling back to

nodes.run

nodes.run

which also failed (no nodes paired).
What we tested:
1. Subagent spawned from the main DM session →

exec

exec

works fine

2. Subagent spawned from this group channel →

exec

exec

denied

3. Owner directly interacts with the subagent session and tells it to use

exec

exec

→ works fine

So the subagent itself has

exec

exec

capability, but when spawned from a channel with

toolsBySender

toolsBySender

deny, it inherits the

deny restriction.
Docs say:
- Subagents run in their own session (

agent:<id>:subagent:<uuid>

agent:<id>:subagent:<uuid>

) with fresh tool policy
-

toolsBySender

toolsBySender

is channel/sender-scoped, shouldn't propagate to subagent sessions
- Tool precedence: subagent tool policy is layer 8, but "each level can only further restrict, not grant back denied tools"
Question:
Is this intended behaviour (channel sender restrictions propagating to subagents)? Or is this a bug where the

deny leaks into subagent sessions? Would

tools.subagents.tools.allow

tools.subagents.tools.allow

be able to override this, or does the "deny always wins" rule prevent that?

FotC�

Friends of the Crustacean 🦞🤝•2w ago•

3 replies

Qearl

question about toolsBySender + subagent tool inheritance

Version: 2026.2.22-2 (npm install, Linux WSL2)
Setup:
A Discord group channel has this config:

"toolsBySender": {
  "*": { "deny": ["edit", "write", "exec", "process"] },
  "id:<owner_user_id>": { "allow": ["*"] },
  "id:<bot_user_id>": { "allow": ["*"] }
}

"toolsBySender": {
  "*": { "deny": ["edit", "write", "exec", "process"] },
  "id:<owner_user_id>": { "allow": ["*"] },
  "id:<bot_user_id>": { "allow": ["*"] }
}

The owner's user ID and the bot's user ID both have

allow: ["*"]

allow: ["*"]

to override the wildcard deny.
Problem:
When the bot spawns a subagent (via

sessions_spawn

sessions_spawn

) from that group channel session, the subagent cannot use
exec
exec
. It's not in its available toolset. The subagent tried falling back to

nodes.run

nodes.run

which also failed (no nodes paired).
What we tested:
1. Subagent spawned from the main DM session →

exec

exec

works fine

2. Subagent spawned from this group channel →

exec

exec

denied

3. Owner directly interacts with the subagent session and tells it to use

exec

exec

→ works fine

So the subagent itself has

exec

exec

capability, but when spawned from a channel with

toolsBySender

toolsBySender

deny, it inherits the

deny restriction.
Docs say:
- Subagents run in their own session (

agent:<id>:subagent:<uuid>

agent:<id>:subagent:<uuid>

) with fresh tool policy
-

toolsBySender

toolsBySender

deny leaks into subagent sessions? Would

tools.subagents.tools.allow

tools.subagents.tools.allow

be able to override this, or does the "deny always wins" rule prevent that?

question about toolsBySender + subagent tool inheritance

Similar Threads

question about toolsBySender + subagent tool inheritance

Similar Threads

Similar Threads

Similar Threads