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 — 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.