# Whose sign-in June uses

> Whose connections run in each place, what reaches an organization, and which tools act as you in the sandbox.

Source: https://www.dearjune.ai/docs/how-june-works/connections

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](/docs/how-june-works/schedules#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](/docs/june-mcp), from Claude Code, Codex or another MCP client, uses the same connections as your own chats.

- Mailboxes and Microsoft 365, its calendar, Teams and files included, start as **Personal only**. [Personal or organization](/docs/integrations#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.

## MCP 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](/docs/integrations/custom-mcp#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](/docs/how-june-works/schedules#when-a-run-fails).
- A plan you shared as its funding source stops paying ([Pay for an organization](/docs/organizations/funding)).

## 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](/docs/security-and-privacy#your-connections)); your GitHub sign-in is added only to requests to GitHub.

Obsidian, 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, changing, cancelling or replying to 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
- archiving, labeling, marking read or unread, or trashing mail in 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
- adding rows to one of your Google Sheets, changing its cells, or editing the text of one of your Google Docs
- a tool an MCP server marks that way
- a sandbox command that could do damage

Reading does not ask for approval. Changes normally ask first, but a rule you set can allow a kind of change without a new click each time. An event that invites nobody on your main calendar also needs no card. Check the account and the proposed change before approving; permission to use a connection is not permission for every action.

**In a chat on the web or in the iOS and Android app**, June asks you with a card for calendar events (new, changed or cancelled), replies to invitations, Teams messages, emails, Gmail tidying 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 change to a calendar event, or a reply to an invitation, it shows the event as it stands (its time, organizer and guests), each field that changes before and after, and who hears about it; if the event changes before you click, June changes 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. For Gmail tidying it says the change in words ("Archive 12 emails"), every label it adds or removes, and the mails by sender, subject and date: the first 20 listed and the rest counted, at most 50 mails per card. **Approve** runs that one step, once, as shown; **Deny** stops it, and June tells you nothing was sent.

For a Sheet the card also shows the spreadsheet, tab and rows, or the cells before and after; for a Doc, every edit with its exact text. If someone changes those cells or that Doc before June makes the change, June changes nothing and asks again.

- The event that invites nobody needs no card: June creates it and shows it as created. Other changes follow your approval rules; some still require a decision for each exact call.
- 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 posts the same card in the thread, as a normal reply, for every one of these steps: an email from Gmail or your personal email account, Gmail tidying, a new, changed or cancelled calendar event or a reply to an invitation, a Teams message, a change to a Drive file, a Doc, a Sheet or a Slides deck, and a tool of a custom server. Everyone in the thread sees the card, as they saw the request. Its buttons are **Approve**, **Allow in this thread**, **Always allow** (with one confirmation) and **Deny**, and **⋯ › Open in June** opens the same card in June.

- 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.
- The thread gets a short result. Service responses and result links go privately to the approver, unless the request was already in a direct message. The card’s available choices depend on the action and your organization’s rules.

**Through June MCP** (Claude Code, Codex and other clients) a step that needs your approval gives you a June link instead of a card: you approve it on that approval page, and the client reports what ran ([how](/docs/june-mcp#when-a-step-needs-your-approval)).

**In a schedule**, a step that needs a new approval does not run. If an older app cannot show the card, open the conversation on the web. 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 custom MCP server’s change follows the same approval rules in supported chats. A sandbox command that needs approval still cannot run, because the sandbox cannot ask for it yet.

## 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](/docs/june-mcp) it reaches nothing that works only in an organization.