feature request: capability management

[supermomonga]

It would be great if capability settings (allowlist or denylist) could be configured for each profile.
Because I want to prevent the agent from performing actions the user did not intend.

For example, it would be great if message posting could be restricted to specific channels, enabling finer-grained control than Slack App/Bot token scopes.

@urugus what do you think about this?

[urugus]

Thank you for the great idea.

I think adding capabilities per profile is a very good direction. Slack App / Bot token scopes alone cannot provide fine-grained controls like "allow only this operation for this profile" or "restrict posting to specific channels," so it makes sense for slack-cli to add an extra layer on top.

That said, I think this should first be treated as a safety rail against unintended actions rather than a strong security boundary. Even if profiles are separated, it does not help much if the agent can still switch to another profile. So if we want this to work as a real constraint for agent usage, we would likely need not only capabilities, but also a separate configuration space for the agent.

If I implement this, I would probably keep the first scope small and focus on write operations such as send, upload, edit, delete, reaction, pin, join, leave, and invite.
Also, if we support channel-level allowlists / denylists, I would want the checks to be based on channel IDs rather than channel names.

So my current thinking is:

• I agree with the idea of per-profile capabilities
• but I would start with it as a safety rail in v1
• and if we want it to be meaningful for agent isolation, we probably need config isolation in addition to profiles

Overall, I think this is a worthwhile direction to explore.

[supermomonga]

I completely agree with your thinking.

Given the premise that it is difficult to prevent unintended API calls by the user with 100% certainty, I believe it is sufficient for it to function as a safety rail.

If, for example, slack-cli were to simply fail the command (by setting a return code that indicates an error), the LLM might look for a way to circumvent it. However, since the LLM is basically well-intentioned, I think it would be sufficient to prevent such accidents if stderr displayed that the command is not permitted.