Whose sign-in June uses
Whose connections run in each place, what reaches an organization, and which tools act as you in the sandbox.
June uses the sign-ins of the person who asked it, in every place. Two exceptions: a schedule runs as whoever set it up; and Obsidian, ownCloud and Tailscale, which act as you for the whole sandbox, never run in shared places.
The person June is answering
| When | Whose connections run |
|---|---|
| You ask in your own chats or projects | Yours |
| Someone tags June in an organization's chat or chooses Ask @June directly, or mentions it in Slack | The person who tagged or asked it, not whoever started the thread |
| Another member steers a reply June is writing | That member's from their message on, with their own model, and their plan unless the organization pays |
| A schedule runs | The person who set it up, on every run |
| June starts a separate thread for part of the work | The person whose message started it |
So two members who ask June the same thing in one thread can get different answers: each comes from that person's own mail, files and accounts. A steer from someone who has since left the organization is dropped.
June knows what that person has connected wherever it answers them: in a chat, in Slack, and in a schedule's runs when the schedule has its integrations toolset on (what a run can use). For each connection it knows the name and, when the connection's last check confirmed one, the account it is signed in as (an email address or a GitHub username), so "check my nunc mail" reaches the mailbox named nunc, or the one whose address is at nunc.immo, without June asking you to connect it again. When June cannot read the list for a moment, it looks the connection up before it tells you something is not connected.
What reaches where
Where you connect a tool decides where June can use it.
| Connection | Your own chats and projects | An organization's chats and projects |
|---|---|---|
| Made on the Integrations page | Yes | Yes, in every organization you belong to, from its first message |
| The same, marked Personal only | Yes | No |
| Made inside an organization, such as with Use work account or a link June sent in its chat | No | That organization only |
June MCP, from Claude Code, Codex or another MCP client, uses the same connections as your own chats.
Codex- Mailboxes and Microsoft 365, its calendar, Teams and files included, start as Personal only. Personal or organization has the steps to change that.
- Every connection of yours, wherever it was made, is disconnected on your Integrations page.
- Slack goes by who the workspace belongs to: a workspace that is yours (Just me) works like your own chats; one that belongs to an organization works like that organization's chats.
TeamsMCP servers and organizations
An MCP server you add on your Integrations page reaches your organizations like any other connection, unless you mark it Personal only.
An organization's admins can also offer a server to everyone in it. That connects nothing for anyone: each member connects their own login in the organization's Integrations section, and that connection works only in that organization. When an admin removes the server, it stops working there for everyone at once (use it in an organization).
When you leave an organization
- Connections you made inside it, and the sign-ins stored for them, are deleted.
- Your personal connections stay as they are and stop reaching the organization.
- Schedules you set up there stay, but their runs are blocked.
- A plan you shared as its funding source stops paying (Pay for an organization).
Tools that act as you in the sandbox
Most integrations run on June's servers, so the code June writes gets their results, never your sign-in. GitHub (with an Obsidian vault on GitHub), ownCloud (or Nextcloud) and Tailscale work from June's sandbox instead. The sandbox still holds no password or token for them, except Tailscale's device key (how); your GitHub sign-in is added only to requests to GitHub.
NextcloudObsidian, ownCloud and Tailscale act as you for the whole sandbox, so June sets them up only in a sandbox that works for you alone: the one for your own chats, and each of your own projects'. An organization's chats and projects share a sandbox among their members, so none of the three is set up there.
GitHub is signed in again for every message instead. In an organization's chats and projects, git and gh work as whoever wrote the message June is answering, with their GitHub in that organization: their personal one unless it is Personal only, or a work account connected there. Commits carry that person's GitHub name. A member with no GitHub there gets none; June never uses someone else's. The members share the sandbox's files, so what an earlier message left there stays, and a command still running from an earlier message can finish with the next writer's sign-in.
A schedule June sets up from chat, or you set up on the form, runs in a sandbox of its own and gets your GitHub wherever it was set up, a Slack channel in an organization's workspace included, with terminal on; in an organization, the GitHub you can use there. (From an organization's chat on the web, a schedule can't be set up yet.) It never gets the Obsidian vault, ownCloud or Tailscale. One June writes as a file under /schedules gets what the place it was written in gets.
A step that needs your confirmation
Some steps are marked as needing you to confirm first:
- creating a Microsoft 365 calendar event
- creating, changing, cancelling or replying to a Google Calendar event
- sending a Teams message
- sending an email from your personal email (SMTP) account
- sending a message, a reply or a draft from Gmail
- a change to a Google Drive file, Doc, Sheet or Slides deck through Google's own API, such as renaming a file June created or commenting on it
- a tool an MCP server marks that way
- a sandbox command that could do damage
GoogleJune never creates, changes or sends anything without your click, except an event that invites nobody on your main calendar. A change through Google's API always asks.
In a chat on the web or in the iOS and Android app, June asks you with a card for new calendar events, Teams messages, emails and Google changes. The card shows exactly what will happen: the account, every recipient, attendee or chat member, the time with its time zone, the subject and the whole text. For a Gmail send it also shows the address it goes out from, and for a draft, the draft as it stands in Gmail when the card appears, with your edits and its attachments; if you change the draft before you click, June sends nothing and asks again. For a Google change it shows what the change does, the exact request June sends, and everything it sends with it. Approve runs that one step, once, as shown; Deny stops it, and June tells you nothing was sent.
- The event that invites nobody needs no card: June creates it and shows it as created. It is a step that only changes your own calendar, like a read; everything that reaches another person or changes something outside the chat asks first.
- Only the person whose message led to the step can approve it, because it runs on their connection. In a shared thread everyone else sees whose it is.
- Sending a new message instead, or pressing Stop, cancels the card. So does waiting: a card nobody answers is cancelled after 24 hours, and a late click is refused.
In Slack, June shows the same card, with Approve and Deny buttons, for three of these steps: a new calendar event (Google Calendar or Microsoft 365), a Teams message, and an email from your personal email (SMTP) account. Only the person whose message led to the step sees the card, because it runs on their connection. Everyone else in the thread sees a note that June is waiting for them to approve a request, never the recipients or the message.
- After the click your card shows the outcome, the note says who approved or denied it and whether it was sent or created, and June replies in the thread.
- Your next message to June in that thread cancels a card you left open, and so do 24 hours. A click on a card that was cancelled or timed out runs nothing, and the card then says why.
- A Gmail send or draft, and a change to a Google Drive file, Doc, Sheet or Slides deck, are approved in a chat on the web or in the app, not in Slack. In Slack June turns the step down before anything is sent or changed, and the thread gets a note saying it needs your approval in June on the web or in the app.
Everywhere else these steps don't run: in a schedule, through June MCP, and in an older version of the app. June turns the step down, nothing is created or sent, and June tells you what it would have done, so you can ask for it in a chat on the web or in the app. A step an MCP server marks, a dangerous sandbox command, and changing, cancelling or replying to a Google Calendar event are turned down in chat too.
What June does not do
- It does not use one member's connection for another member's request.
- It does not move a connection between your personal space and an organization; connect it again where you want it.
- Through June MCP it reaches nothing that works only in an organization.
Where a conversation lives
Your own chats, projects, an organization's chats and Slack differ in who sees them, whose sign-ins and plan June uses, and what it remembers.
How schedules run
The exact rules behind reminders and schedules: what a run can use, where results go, who pays, timing and time zones, missed runs and failures.