A Claude session that lives on your machine, with your files and your tools. One click and your team joins — with the context you explicitly choose to share.
step 1
Chat locally
Your Claude Code session, on your machine, with your codebase + MCPs.
→
step 2
Click share
Choose what context comes along. Generate a link.
→
step 3
Team joins
Live conversation with the same agent. Permission-gated.
02Local Claude session · before sharingYour machine · your codebase · solo
claude — ~/code/cortex — main — claude-sonnet-4-6
▶I'm trying to figure out why our shared-hashtag visibility query is missing notes for users who joined the workspace after the share was created. Show me the relevant code.I'll trace through the visibility resolution. Let me start with getVisibilityWhere: ⎿ Read server/src/service/search-service.ts (217 lines) ⎿ Read server/src/service/note-sharing-service.ts (278 lines)Found it. getHashtagGrantsFor filters by principal: email. When a user's email changes after a share is granted (e.g. they update their account), they lose access until you re-share. There are 3 ways to fix this...▶Wait — Sarah just messaged saying she sees this too. Can I share this chat with her so she can pick up where I left off?
03Share dialog · what comes along when promoting local → sharedConversation history is automatic · everything else is opt-in
Share this chat
Promotes the local session to a shared workspace. Conversation history comes automatically; context is per-item.
Who can join
Or share the link below — anyone with the link can view (no prompting).
Link
Context to share
Mode
What "share" actually does
Promoting a local chat to a shared workspace does three concrete things:
Snapshots the conversation — every turn so far is mirrored to a cloud workspace. Local session keeps running, cloud is the new source of truth for invited users.
Projects the context you picked — files mounted read-only into the cloud sandbox; MCPs you didn't tick stay on your machine.
Routes new prompts through the cloud agent — when you or a teammate prompts, the cloud session responds with the shared context. Your local session pauses.
What it doesn't do
Doesn't give teammates terminal access on your machine
Doesn't share your unticked MCPs (Linear, Gmail, etc.)
Doesn't permanently copy your codebase — read-only mount, revoke anytime
🔒 Revoke at any time. Removes cloud access; conversation history stays in your local session.
04Promotion in flight · what gets carried overTypically ≤ 8 seconds · spinner shows live progress
Promoting to shared workspace…
Sharing with Sarah · cortex/server/src/service · multiplayer mode
cortex/server/src/service · 28 files · ~/tmp/sandbox-0a3f mounted on GCE VM
●
Sent invitation to sarah@ideaflow.io
Email queued · in-app notification dispatched
○
Switching prompt routing to cloud agent
Local session pauses · next prompt goes to shared workspace
05Shared workspace · multiplayer prompting in action3 humans + agent · presence avatars · live typing
Visibility-bug investigation
JSD🦊
J
Jacobyoustarted · 14 min ago
I'm trying to figure out why our shared-hashtag visibility query is missing notes for users who joined the workspace after the share was created. Show me the relevant code.
🦊
Claude13 min ago
Found it. getHashtagGrantsFor filters by principal: email. When a user's email changes after a share is granted, they lose access until re-share.
Oh yeah this is what I was seeing. @Claude can you check if there's a similar bug in getDirectShareNoteIdsFor? I think the same email-changes-and-loses-access pattern applies.
🦊
Claude1 min ago
Yes — same bug pattern. getDirectShareNoteIdsFor at line 80 also queries { principal: email, principalType: "EMAIL" }. If we want a real fix, we should either:
1. Promote the principal from EMAIL to USER_ID on first sign-in (with a backfill migration)
2. Store both, prefer USER_ID when present
Option 2 is safer for existing rows. Want me to draft the migration?
draft: option 2 plus we should write a regression test that…
Reply as Jacob · type your message or @Claude…
⌘↩ send · ⌥A attach · ⌥/ commands
06Phone · the shared workspace on iPhoneMobile-first per yesterday's UX audit · stateful controls
9:41📶 🔋
‹
Visibility bug
JSD
JJacob · 14m
Why is the shared-hashtag query missing notes for users who joined later?
🦊 Claude · 13m
Found it. getHashtagGrantsFor filters by email — if email changes after share, users lose access.
SSarah · 2m
Same bug in getDirectShareNoteIdsFor?
🦊 Claude · 1m
Yes. Same pattern at line 80. Two fix options...
Reply as Jacob…↑
9:41📶 🔋
×
Share this chat
Promote this Claude session to a shared workspace.
Who joins
Context
Mode
07Per-resource ACL · the differentiatorEach context resource has its own permission · the moat against ChatGPT shares
Context for this shared chat
Choose what the agent can see, per resource. Default is private — share explicitly.
💬
Conversation history (7 turns)
Always shared — that's the whole point of promoting to a workspace.
📂
cortex/server/src/service
2 files Claude has read · 26 more in directory · mounted read-only on cloud sandbox
🧠
Noos memory graph
1,847 nodes · your personal knowledge graph. Stays on your machine unless you specifically share.
🔧
Linear MCP
Your Linear workspace · current sprint, issues, comments. Sensitive — private by default.
🔧
Gmail MCP
Personal inbox · always private. Cannot be shared on multiplayer.
09Agent-first · share via natural language, not just a buttonOne endpoint · four surfaces · the architecture
Conversational share
The share isn't just a button — it's a tool the agent can call. You say it, the agent does it.
claude — bettergpt session 0a3f-7d12
▶Hey, share this with sarah@ideaflow.io and david@ideaflow.io. Let them see the service/ files but not my Linear or memory graph.Sharing this chat to a multiplayer workspace… ⎿ share_chat({
recipients: ["sarah@ideaflow.io", "david@ideaflow.io"],
context: {
files: ["cortex/server/src/service"],
mcps: [],
memory: false
},
mode: "multiplayer"
}) ⎿ ✓ Created workspace · 0a3f-7d12 ⎿ ✓ Mirrored 7 turns · mounted 28 files read-only ⎿ ✓ Invited 2 people · email + in-appDone. Shared with Sarah and David in multiplayer mode. Link: bettergpt.ai/c/0a3f-7d12 Shared context: 28 files in service/ (read-only) Kept private: Linear MCP, Noos memory, Gmail MCPThey'll get notified now. Your local session pauses while we'rein the shared workspace.
One endpoint · four surfaces
POST /api/sessions/:id/share is the single source of truth. Four caller surfaces wrap it.
1 · UI
Share button
User clicks "⤴ share this chat" → dialog → submit
2 · Agent
Tool call · share_chat
In-conversation. User asks in natural language, agent invokes the tool.
3 · MCP
mcp__bettergpt__share_chat
External agents (Cursor, Codex, other Claude) discover via .well-known/mcp/server-card.json
4 · CLI
bettergpt share --to sarah
For scripts, CI, automation. Direct REST also.
Why all four: conversational share is how users actually want to invoke this. MCP enables cross-session handoff (Codex → betterGPT). CLI enables scripts. One endpoint means one auth path, one audit log, one set of edge cases.
08Decision · build inside betterGPT vs new repoTwo parallel paths · we're doing both
Path A · inside betterGPT
primary
Continue on bettergpt/prototype-core. Add Story 6 (group/shared workspaces) as the next milestone after solo polish ships. One product, one brand, sequential roadmap.
Pros
Reuses 30+ commits of prototype momentum
Single brand · bettergpt.ai already owned
User-stories doc already includes group/sharing in Story 6
Solo demos validate the loop before adding complexity
Cons
Inherits Cortex tech debt
Multiplayer is bolted onto solo-first design
Path B · new project
parallel
Stand up ~/code/shared-chats/ as a separate repo. Multiplayer-first architecture. Fresh choices (Postgres, no god file, Cloud Run on existing GCP). Vendor Cortex's ClaudeSessionEngine.
Pros
Clean architecture · no inherited debt
Multiplayer-first product · different positioning
Independent shipping cadence
Two-product portfolio (solo + team)
Cons
Two codebases to maintain
Brand fragmentation if not careful
Cortex modules to vendor (3-file lift)
Doing both in parallel. Path A (betterGPT) is the path to a real product fastest. Path B (new project) is a hedge — if betterGPT's solo-first frame blocks multiplayer cleanly, Path B is ready to absorb the design. The mockup above applies to both — same UX, different host. The architectural decision can defer; the design doesn't have to.