Daniele
72fa40708a
Nightly Build / build (push) Successful in 9s
Three of the surfaces a user asks about most had nothing in `docs/`, so the assistant answered from guesswork: the chat itself (its two layouts, the tab bar and what lands on which tab, every control around the composer, the slash commands it must never forward to the model), the Inbox (why background work asks there rather than in the chat, and that an unanswered card is a stopped job, not a slow one), and security groups — the honest answer to "why does it keep asking me for permission?", including what a group is *not*: not a mode, not a data boundary, and not advisory. Each page states the misreadings users actually arrive with, since correcting those is most of the work; the tables list what the person is looking at, not what the code does.
50 lines
4.7 KiB
Markdown
50 lines
4.7 KiB
Markdown
# The Inbox (things waiting for a human)
|
||
|
||
The Inbox (sidebar → **Inbox**) is the one place where everything that is *waiting for this person* collects. The red number next to it is the count of pending items, and it updates by itself — no refresh needed.
|
||
|
||
The rule that explains the whole page: **work that happens in front of the user asks in the chat; work that happens out of sight asks here.** When the assistant needs permission mid-answer, the card appears inline in the transcript where the work is. When something running in the background needs an answer — a scheduled job, a background task, a connector — it has no conversation to interrupt, so it files a request here. Background tasks also surface theirs above the message box of the chat that started them (see [tasks.md](tasks.md)), but the Inbox is where they all end up.
|
||
|
||
Everything in the Inbox is **someone's work sitting still**. Until it is answered, that job is not slow, it is stopped.
|
||
|
||
## The three kinds of card
|
||
|
||
**Approval** — a tool call the rules say a human must confirm: running a command, writing into shared memory, sending something out. The card shows which tool, which agent asked, and the arguments that matter (path, command, URL, recipient…), with the full request available behind *Show raw JSON*.
|
||
|
||
**Question** — the agent itself is asking something it cannot decide: which of two files was meant, whether to use the work or the personal address. Some come with suggested answers as one-click chips; the answer box takes anything, Enter sends.
|
||
|
||
**Input** — a connector asking for a value directly, usually a login code or an API key. When the value is a secret the field is masked, it is sent once, and it is never shown again anywhere in the interface or written to the conversation.
|
||
|
||
## Answering an approval
|
||
|
||
- **Approve** runs the call, once.
|
||
- **Reject** asks for an optional reason. The reason is worth writing: it is handed back to the agent as the result of the call, so it can adjust and try something else instead of guessing why it was refused. A bare rejection just tells it "no".
|
||
- **×tool ▾ (15 min / 1 hour)** approves *and* stops asking for **that same tool** for that long — nothing wider. Approving "label this email" never un-gates "send this email".
|
||
- **Session** does the same for the rest of the conversation.
|
||
|
||
The time-limited buttons are missing on a request that has been waiting since before the server restarted; that one can still be approved or rejected normally.
|
||
|
||
A `deny` rule is never bypassed by any of these buttons: what the rules forbid outright never reaches the Inbox in the first place.
|
||
|
||
If someone finds themselves clicking the same approval every day, the answer is not a longer bypass — it is a rule change on the Security page, which is [security-groups.md](security-groups.md).
|
||
|
||
## Where a request can be answered
|
||
|
||
The same pending request appears everywhere at once: in the Inbox, in the chat that raised it, above the composer for a background task, and on the paired phone if the mobile app is set up. **Answering it in any one of those settles it everywhere**, and the others drop the card on their own. There is no "answer it in the right place".
|
||
|
||
Closing a card in the chat with ✕ is not an answer: it puts the card away and the request keeps waiting in the Inbox.
|
||
|
||
## What waits, and for how long
|
||
|
||
- Requests **do not time out**. One left overnight is still there in the morning, and so is the job behind it.
|
||
- They **survive a restart of the server**, because they are recorded, not just held in memory.
|
||
- Stopping the conversation or the task that raised a request (the ⏹ button) cancels its pending requests along with it — the card disappears because nothing is waiting for it any more.
|
||
- Every item belongs to one person. An admin does not see, and cannot answer, another member's Inbox.
|
||
|
||
## Common questions
|
||
|
||
- *"The assistant isn't doing anything."* — check the Inbox first. A stopped job with a pending card is the single most common cause.
|
||
- *"Why is it asking me at all? It did this yesterday without asking."* — either the bypass from yesterday has expired, or the conversation is on a different security group.
|
||
- *"I clicked reject by mistake."* — nothing is broken: ask again in the conversation. The rejection was recorded as the result of that one call, not as a standing rule.
|
||
- *"Can I make it stop asking for this forever?"* — yes, but that is an admin change to the rules ([security-groups.md](security-groups.md)), and it is worth saying out loud what it means: the assistant will then do that thing unattended.
|
||
- *"It asked for a password — is that safe?"* — the value goes to the connector that asked for it and is never echoed back, logged into the conversation, or shown again. Still worth checking *which* connector is asking, and the card says so.
|