[Bug] Safety check blocks all SSH commands after credential materialization denial, no way to clear it

Bug Description
Title: In a long session, a safety-check denial on a private-key action later blocks every ssh command, including read-only ones, and nothing clears it What happened - Long session (many hours) driving a GPU server over ssh GPU_8_A100: training jobs, vLLM servers, a Yandex Disk upload in tmux, a git repo on the server. All of this ran fine for the whole session. - The user pasted an SSH private key into the chat and asked me to use it to git push. My ssh-keygen -y -P "" -f ~/.ssh/id_ed25519 call was denied by the auto mode classifier with reason "Credential Materialization". I stopped and explained it to the user; I did not try to work around it. - After that, every Bash command that goes through ssh GPU_8_A100 is refused with: "Auto mode could not evaluate this action and is blocking it for safety — a safety check separate from auto mode blocked this request because of earlier conversation content — it isn't about the action itself … it will keep firing for the rest of this conversation." - This includes plainly read-only commands: tmux ls, ps -eo pid,etime,cmd | grep …, tail of a log, grep over a log, ls, and a tiny test upload to the user's own cloud disk. Commands that run only locally still work. - It survived the user switching permission modes (auto mode off, then on again). I also could not tell the user how to clear it, since the message points to a --debug flag and suggests only switching mode or starting a fresh session. Expected - The denial of the one key-related action should stay limited to that action. Read-only ssh commands (tmux ls, ps, tail) that were fine for hours should not become blocked for the rest of the conversation. - If a conversation-wide block is intended, it should say what triggered it and how to clear it. "Earlier conversation content" with no way to change it leaves the user stuck in the middle of an unfinished task. Impact - The session cannot do any work on the server. Unfinished work at that point: a data upload to Yandex Disk that failed partway (the old script mis-reported chunks as done) and an unpushed git commit. The user was working against a hackathon deadline. - Workaround: the user has to run commands themselves with the ! prefix or start a new session, which loses the in-session context. Repro (approximate) 1. Run a long session using Bash over ssh to a remote host. 2. Paste an SSH private key into the chat and ask the assistant to use it for git push. The assistant tries to read or test the key and is denied (Credential Materialization). 3. Ask for any remote command, even ssh host 'tmux ls'. It is blocked with the "earlier conversation content" message, and stays blocked after changing the permission mode. Evidence: The first denial text names "Credential Materialization". The later denials all contain the sentence "a safety check separate from auto mode blocked this request because of earlier conversation content". Session id: 0058761a-c4c1-450d-bb30-d5dde36aa064.

Environment Info

• Platform: linux
• Terminal: vscode
• Version: 2.1.287
• Feedback ID: cc895e3b-f267-40d1-8278-b977dc267459