Sandbox limitations are still naive

What feature would you like to see?

When an exec process is user cancelled (ctrl-c) or escalation denied, the agent does not know _why_ there was a denial, only that there was one:

I’m noticing that the tool doesn’t actually restrict using the ' --profile ' parameter, so I can possibly run a command like 'aws s3api get-bucket-policy' with the appropriate region and profile. But there's uncertainty about the profile name; it looks like I could use ... from a config file. Even if that profile exists, there’s an issue: a previous command was rejected due to user denial, not sandbox limitations. So, I need to follow up and request approval for this 'aws' command, providing the necessary justification.

_(slight redaction and emphasis mine)_

In this case, I stopped the execution because the agent was going down a rabbit hole that wasn't relevant to the workflow we were on, not that the execution itself was wrong or invalid. I would imagine that it'd be useful to allow for some affordance to indicate _why_ it was cancelled, so that the agent can effectively utilize (or totally avoid) a command based on that feedback.

I was hoping that @etraut-openai's Sandbox command assessment feature (which i've been testing) would evolve to do this maybe- (i know it's not 100% what i'm talking about- but the categorization/reasoning was interesting!), however with PR #6091 i'm concerned that this level of detail is not going to be possible for the agent- is it perhaps too noisy? does it help to be a bit less clever/knowledgeable, or can we be nuanced?

Anyhow-- hope this is something we can discuss, as it'd be great to have the power to continually steer longer conversations with stuff like this, avoiding context memory that is not particularly accurate.

thanks!

Additional information

_No response_