---
title: Shared with me (the invitee half of Multiplayer Sessions)
---
# Shared with me (the invitee half of Multiplayer Sessions)

## What it is

**Shared with me** is a sidebar entry under **Communication** that lists sessions *a teammate
shared in* — never your own. Opening one shows that conversation read-only, live, in your own
Omniscio; if the owner granted you can-reply, a composer appears at the bottom and your
messages go into their session attributed to you by name.

It is the receiving end of the owner's **Share this session** dialog. The two halves are one
feature (`multiplayer-sessions`), gated off by default, and are entirely separate from the
unrelated **Shares** feature, which publishes artifacts to a public URL.

## Where to find it

**Shared with me**, a sidebar entry under the **Communication** group.

## How it behaves

### Why it never lists your own sessions

A new share is created with an empty participant list — **the owner is deliberately not a
participant on their own share.** The query behind this surface is
`participantUids array-contains <your uid>`, so your own shares correctly never appear here.

That is not a quirk to route around: the owner and the invitee read through genuinely
different paths. The owner reads their share directly by id (to manage participants); the
invitee reads via the participant query. Testing the owner down the invitee's path returns an
empty list and looks exactly like a bug.

### What the person sees

| State | What shows |
|---|---|
| Nothing shared with you | An empty state saying so |
| Signed out | A distinct "sign in to see shared sessions" state — never conflated with "nothing shared" |
| The request failed | A distinct failure state — also never conflated with empty |
| A share you can read | The mirrored conversation, oldest first, with a Load more button |
| Granted `replier` | A reply box, with your usual Enter / Ctrl+Enter send preference |
| Granted `viewer` | **No reply box at all** — not a disabled one |
| The owner is away | Your sent reply reads as *queued*, never as an error and never as a fake success |
| The share was revoked | It disappears from the list |

The three "empty-looking" states are deliberately distinguished because the backend returns an
empty list for all three, and telling a signed-out person that nothing is shared with them
would simply be false.

### Cost

Reading costs nothing. **Replying spends the owner's tokens**, because your message drives
their agent in their session — which is why can-reply is granted per person and revocable.

## Related

- [overseers.md](overseers.md) — an unrelated always-on session, not this.
- The owner-side dialog, the trust boundary, and the invariants that lock all of it live in
  the feature contract: `.claude/memory/contracts/multiplayer-sessions-contract.md`.
