What a watcher sees when you share a live build
A watcher on a Flockshow link sees your page as it looks in your browser, the name of each cursor and a short label for what it is doing. They never receive your file paths, your prompts or your source code.
The rest of this post is the full list, and a way to see it for yourself.
Why a screen share is risky
When you share your screen, you share pixels. Everything in the frame goes out: the terminal with your last prompt in it, the file tree with your client’s name, the .env tab you forgot was open.
People who build in public get round this with a second monitor, a clean browser profile and a habit of looking twice before they go live. It works until the day it does not.
A watch link starts from the other end. It sends a fixed list of things and nothing outside it.
What reaches a watcher
| What | Example |
|---|---|
| Your page | The page your app is showing, as it looks in your browser |
| Each cursor’s name and colour | “Kai”, in rust |
| A short label | “rewriting Hero” |
| The kind of edit | Copy, style, layout or logic |
| Proposed page text | The words a session is about to put on the page, shown just before they land |
The label is a status word and a bare file label. “Hero” is sent. “src/components/Hero.jsx” is not, because path characters are removed and the label is cut at 40 characters.
Proposed text is capped at 80 characters. Any word in it that looks like a path, a web address or a source file is dropped. It is taken only from text that will be visible on the page, never from attributes, expressions, comments or other code. If you would sooner watchers saw each change only once it has landed, switch it off in the session list.
What never leaves your computer
- File paths, folder names, file extensions and line numbers
- Your prompts
- Your source code
- Session ids and tokens
- Your Claude sign-in
These are not filtered out on a server. They are never sent, so there is nothing on a server to leak.
Hiding part of the page
Some pages show things a stranger should not read: a customer’s email in an admin table, a revenue figure, a key on a settings screen.
Mark the element as private in your code. Its text is then masked on your computer before the page goes anywhere. A watcher sees that something is there and cannot read it. A session’s proposed text for a private element is never sent either.
How it is tested
A claim like “your prompts never leave” is only worth something if a test can fail on it.
The product has one. It plants unique marker strings in four places: a prompt, a folder name, an attribute in the code and a session id. It opens a room, joins as a watcher and reads every message that watcher receives. If any marker appears, the test fails.
It also checks that the proposed page text does arrive. Without that, the test could pass by sending nothing at all.
See it for yourself
You can look at your own room the way a stranger would.
- Start a room and copy the link.
- Open the link in a private window, so you are a stranger to your own room.
- Put the two windows side by side.
- Give a session a prompt with an odd word in it, such as “zebra-umbrella”.
Your terminal shows the prompt. The watcher’s window shows the page and the cursor, and the odd word appears there only if the session writes it onto the page itself.
What is stored afterwards
While the room is live, your page is held in the relay’s memory so it can be passed on. It is not written to disk, and it is gone when the room ends.
What is kept is a short record: who hosted the room, when it started, how long it ran and how many people watched at its peak. The page content is not in that record.
The short version
A screen share sends everything and trusts you to tidy up first. A watch link sends a short list and cannot send the rest. If you run sessions on client work, that difference is what lets you share a link.