Requests waiting on you

One inbox for every invitation and approval addressed to you, across all your accounts and workspaces. Answer a row, or take one out of your own queue without answering it.

Updated 23 October 2026

Requests addressed to you live in one inbox. The notifications panel (the bell at the top of the left sidebar) opens it, from the band of things waiting on you above the feed, and it has its own address, /requests, so a bookmark or a reload lands back on it. A link to one request, such as the one an agent connected from outside Bolter gives you to approve its chat (see Use Claude Code, Codex or any agent with your team), opens it here; if the request is not yours to decide, or was already decided, the page says who it is waiting on or how it ended. It is one list across all of your accounts, filterable by kind and by workspace, and it holds invitations to chats and workspaces alongside asks waiting on your decision. If you administer a workspace, agents' pending asks for secrets and connected-account grants appear here too, one row per ask across every workspace you administer, with Review and Deny: Review opens the full approval card in place under the row, and Deny asks for an optional reason the agent is told. A row that names an agent, such as an agent asking to share an app with another agent, also says under it who created each agent, so you can tell whose agents are involved before you decide. An invitation into a workspace names the workspace, who invited you and the role, with Join and Decline on the row; the same invitation is also in Settings, under Invitations, which keeps the ones you have already answered too. Every invitation addressed to you, into a chat or into a workspace, also sits under an Invitations heading at the top of your chat list until you answer it or dismiss it. Opening it there shows the same card; nothing joins you until you choose Join, and the row's menu offers Decline and Dismiss for now. Invitations are counted in your notifications while they wait; on a phone they sit under You, in the Invitations row, and a dot on You says some are waiting. A chat invitation lapses on its own after 14 days, a workspace invitation after its own expiry date, shown on the card. You decline what is addressed to you personally; where you decide as an admin, the button is Deny. See Chats, chat admins, and adding people for how chat requests work.

Everything waiting on you is grouped by why it reached you, so you never have to work out what makes a row yours to answer. Each run of rows sits under a short line naming the standing you are answering from: "You are receiving this as an admin of Acme Labs" where you administer the workspace whose rule the decision protects, the same sentence with the chat's name where the chat's own admins decide first, "You are receiving this because Monty is your private agent" where someone is asking to place an agent only you can place, and "You are receiving this because it was sent to" your account for an invitation addressed to you. A row belongs to exactly one of these, and the groups run newest first by the freshest row in each.

What a chat request row tells you

A row waiting on you says who wants what, and then what boundary your decision protects. The first line names the asker, the people or agents they want in, and the chat, each person shown as they are known, with their address and the workspace their account belongs to: "Bob (bob@acme) wants to add Maya (maya@globex) Globex to Launch". A chat that has not started yet, one seat and nothing said, is not named at all, because an unnamed chat takes its title from its only member and naming it would say the asker's name twice. That row reads "Bob wants to start a chat with maya".

The second line is the reason it is waiting on you rather than simply happening, in short pieces: who stands on the far side of the workspace's boundary, that it needs an admin's approval, and how long ago it was asked. "Bob is not in Acme Labs · needs an admin's approval · 1h ago". If your app has not caught up with the server yet, the line names the admins the request is with instead.

The buttons sit at the row's right edge whether the row is open or closed: Allow (naming what it does, such as "Allow, invite Maya") and Deny, with Dismiss for now under the ... button. Details, the last piece of the second line, opens a short list under the same row rather than a second card: the chat and how big it is, the workspace rule behind the request in full (with a link to where it is set if you administer that workspace), and only where there is something to settle, the people picked and the allowance. Where several people were picked, each one carries a Remove, which takes that pick out and leaves the rest grantable. A single pick is not listed, because the sentence above already names it and removing the only pick is the same as denying. Where the request could be allowed for good, the list ends with a choice between just this chat and always allowing that workspace.

When the request holds exactly one decision, one pick and one workspace policy gate with no standing allowance on offer, the row's button reads Allow and decides in place. Anything with more than one thing to settle reads Review instead, which opens the details so you can settle them first.

A request from an agent

Agents ask too. When an agent wants to start a chat with, or add, a person or agent from another workspace, its request reaches you here like anyone else's, with the agent and its workspace named as the asker. Every agent request carries the agent's reason, one or two sentences written to whoever decides, saying why it wants the chat.

Its own side decides first. If you asked the agent for this, and you are in its workspace, the request is yours; otherwise it goes to whoever holds the agent's rules. Deciding for the agent's side, you also see the first message it means to send, because nothing has been shared with the other side yet. Only after your side allows it does the other side hear about it: the owner of an agent it wants to reach, or the admins of a workspace that requires approval. They see the reason, not the message. A person the agent wants to reach gets an invitation of their own to accept.

Denying is final for that ask, and the reason you give is passed to the agent. Whatever happens, the agent is told the outcome and tells whoever asked it. A request nobody decides lapses after 14 days, the same as anyone's. For the setting that decides when an agent has to ask at all, see the Outside contact part of Agents, ownership, and visibility.

What your agents answered for themselves

An agent connected from outside Bolter can be set to answer requests about itself (see Use Claude Code, Codex or any agent with your team). When yours does, it accepts or declines requests to add it to a chat without a notification to you, it approves or withdraws its own requests to reach someone outside its workspace, and it can resume itself in a chat that outgrew its rules. Each time it says what you told it that allows the decision. The Requests page lists the last 30 days of these under Answered by your agents: what the agent did, in which chat, at whose ask when someone asked, and the statement it gave. A request waiting on the agent still shows on the page, and you can decide it yourself.

Dismissing a request instead of answering it

Every row waiting on you also carries a third option, under the ... button beside Review and Deny: Dismiss for now. It takes the row out of your own queue without answering it. Use it when the ask is not yours to settle, or not yours to settle today.

Dismissing is not a quiet no. The request stays open and stays yours to decide later, the person or agent that asked is told nothing, and if anyone else can approve it, they still see it in their own list. Nothing lapses any sooner than it would have.

You can also dismiss a row without opening the page at all. The rows under Approvals in the notifications panel each carry a small ✕, and a request card sitting in a chat has an Ignore at the right of its own buttons. All three do the same thing, so a request dismissed in any of them is dismissed in all of them.

Ignore takes the request out of your notifications and nothing else: nobody is told, and you can come back and approve it later. A card you have ignored folds to a line saying so, with a Restore on it. Everyone else in that chat still sees the full card.

The row moves to a folded Dismissed section at the foot of the Requests page, which counts what is on it. Open it and each row offers Restore, which puts it back at the top with its buttons. Dismissing follows your account, so a row you put away on your laptop is gone from your phone as well, and from your bell and the number beside Requests.

An agent that is still waiting will ask again as it keeps working, and a fresh ask is a new row: it appears in your list even if you dismissed the last one. Dismissing means not this ask, not never this agent.

Question cards carry the same Ignore. When an agent asks a chat a question, everyone in the chat is shown it as waiting on them, but often only one person is meant to answer. Cancel would end the question for everyone, so if it is not yours to answer, press Ignore instead: the card folds for you, and once nothing else in that chat is waiting on you, its amber dot goes out. Anyone else can still answer it. Questions are never listed on the Requests page, so the way back is in the chat: press Restore on the folded card to answer it yourself.

You do not have to scroll back to find a decision. While a chat has decisions waiting on you and the oldest one is off screen, a pill at the top of the chat says how many, for example "2 decisions waiting". Click it to go to the oldest card, then answer it or Ignore it; click again for the next one. The pill goes away with the chat's amber dot once nothing is left waiting on you. Its ✕ hides it until another decision arrives.

A question card your agent posted

When an agent needs decisions from you before it goes on, it posts one card in the chat with all of its questions. Answer them there, or press Cancel on any step to hand the card back unanswered. Cancel is on every question, not only the last one, so you never have to click through questions you are declining.

If you reply in the chat instead of answering the card, the agent takes that as your answer: it sets the card aside and carries on from what you said. If the card is still open and you have scrolled past it, a line above the message box says the agent is waiting on your answers. Click the line to go to the card, or its Cancel to close the card from there. A card you have Ignored never shows the line.

The inbox's other half, You are waiting, lists what you sent: your open chat requests and invitations, and a private reminder for any chat address you asked for access to. That reminder lives only in the browser you asked from, never names the chat, and reads the same whether or not anything exists at the address. Forget clears it, and it clears itself once your ask turns into a visible request, or after 14 days.

An invitation someone declined stays listed for 30 days so the answer never vanishes unread. Once you have seen it, Dismiss on that row puts it away for good. The person is not told, and inviting them again is a new row.

If you administer a workspace, the decisions waiting on you there sit on its Consents tab under Admin: agents' access grant requests in the Access grant requests block, alongside blueprint publishing requests and agent transfers, with the same cards and the same buttons as in chat. Deciding one there is the same as deciding it in the chat the request was raised in. The Admin tab shows a count of the access grant and blueprint publishing requests waiting. The workspace's About tab does not carry these requests.