Answering the user confirmation prompt
When a change is neither clearly safe nor a proven attack, the poison0 agent holds it and asks. This page covers answering: what the user confirmation prompt shows, what Keep and Reject do, and why no answer is a reject.
What the user confirmation prompt shows
The prompt shows only the added line, quoted from the file so it never reads as the poison0 agent speaking:
| Shown | Meaning |
|---|---|
| File | Full path of the changed file |
| Changed | When the line was added, taken from the data |
| The new line | The added line only, quoted verbatim; rest of the file not shown |
| Recommendation | One plain sentence; nothing nudges you toward Keep |
Only the added line is shown, not the whole file and not a score. When the poison0 agent decides to ask is covered in user confirmation prompts.
Keep or reject
Two buttons, each naming what happens to the held line:
| Answer | Outcome |
|---|---|
| Keep | Content left in place and recorded as approved by you. That exact content becomes the new reference point, so the same finding is not raised again; the approval is visible in the console. |
| Reject | Line removed, file put back to its safe state. Quarantined, not deleted, so it can be recovered. |
| No answer | Treated as Reject: rolled back to the safe state. |
No answer is a reject. Timeout, Escape, closing the prompt, a prompt that appeared mid-typing, or no desktop to show it on: every path that is not an explicit Keep rolls the change back.
The hold window
- Held, not applied: file keeps its last clean content until you Keep.
- Deadline to answer: a hotter change gets a shorter one.
- Absolute cap: an undelivered prompt rolls back once an outer time limit passes.
- Keep sets a reference point: the file is left as written and that exact content is recorded as approved by you, so it is not raised again. Visible in the console as a human approval.
A reject is a reversible quarantine, so a mistaken reject costs only rewriting the line. The safe-by-default stance is fail-closed.
How the user confirmation prompt is protected
Trustworthy because of where the question travels and who may reply, neither resting on a secret poisoned content could read:
- Local channel, never the network: a peer-credential channel on the machine, a Unix-domain socket on Linux and macOS or a named pipe on Windows.
- Kernel vouches for who answers: only the signed-in desktop session may reply, re-checked live on every answer.
- No forgeable token: authenticity comes from the kernel-vouched account boundary, not a nonce or token on the wire.
| Platform | How the responder's account is vouched |
|---|---|
| Linux | The kernel reports the connecting account (SO_PEERCRED), taken at connect time |
| macOS | The kernel reports the connecting account (LOCAL_PEERCRED), matched to the active console user |
| Windows | The pipe server reads the client's account token (ImpersonateNamedPipeClient, identification level) |
A poisoned agent or file cannot fake a Keep. Connecting proves nothing; only an answer from the active signed-in account is accepted.
Read next
More: user confirmation prompts and headless devices, fail-closed, and what Cloud mode sends in Cloud mode.