Project Share Link vs Clone: What Readers Can Actually See

A project share link feels like the smaller grant. They open a page, read what they need, close the tab, and nothing has left your account. A clone feels like the bigger one, because the files end up on someone else's disk. For a PrjLab repository that ordering is wrong, and the place it bites you is exactly the case where you're careful: sending a project to a client, an external reviewer, or a drive-by contributor who is not on your team.

Access to a private repository is granted to a person, by handle, with a role. The reader role covers both viewing in the browser and cloning. So the browser view is not a weaker tier of access that you can hand out more freely. It is a rendering of the same grant. The question to answer before you paste anything is not "link or clone", it's "what is in this repository, and which role is this person getting".

What follows is what renders in the browser, what the CLI keeps out of the repository in the first place, and how the two roles actually differ.

The browser view is a rendering, not a permission level

Repositories are private by default. If you paste a URL to someone who isn't a member, they get nothing. If you add them by handle as a reader, they can browse every version in the browser and run prj clone against it, and they can download the repository or any single version as a .zip from the browser. There is no view-only tier that stops the download.

Making a repository public changes the shape of the exposure rather than its depth: anyone can read and clone it at prjlab.com/handle/name, and it shows up on Explore, where people who were never sent a link can find it.

What a project share link actually puts on screen

Each push creates an immutable version. Open one in the browser and you get the file tree at that point, a list of what changed in that push, and a line diff against the previous version.

The part people underestimate is that the three context types render like any other file:

.prjcontext/
  instructions/   project instructions (root CLAUDE.md / AGENTS.md are recognised too)
  memory/         decisions, notes, open questions
  sessions/       the conversations you chose to keep

A reviewer who came to look at a module usually starts with the change list, then the diff. If your last push touched memory/decisions.md and added a kept transcript, those are the first two entries they see, sitting above the code change they were invited to look at. That is often fine and occasionally awkward: a decision record written for yourself at 23:00 reads differently to a client who is named in it.

The cheapest guard is to browse the project in the browser yourself, in the same version you're about to send, before you send it.

What stays out by design, not by luck

Some of the risk is handled before anything reaches the browser. The CLI skips obvious secrets (.env files, key files, credential folders) and anything matched by .gitignore or .prjignore. It never looks at global assistant folders, other projects on the machine, or machine credentials. Files are encrypted at rest and served only to current members, and hosting is in the EU.

Two limits on that, both worth internalising:

• The skip list is a safety net, not a complete secret scanner. prj status tells you what would be captured, and reading it is the step that catches the config file nobody thought to ignore.
• A credential pasted into a session transcript is content, not a secrets file. Nothing flags it, and it travels with the repository to every reader. Transcripts are the leak path that keeping secrets out of your AI context spends most of its time on, for this reason.
• PrjLab can read private content in order to render previews and serve clones, so this is encryption at rest, not end-to-end. The membership list is the real boundary.

Reader and writer are the two trust levels that exist

Framing the decision as clone vs share link hides the distinction that actually governs access.

So the clone adds nothing to what a reader is permitted to see. What it changes is time and location. A clone is a point-in-time copy on their machine and it stays there; browser access always shows current state and stops the moment you remove them, which takes effect immediately. Revoking never reaches back into a copy somebody already pulled down. The practical difference between the two is covered in more depth in what a clone includes and what it doesn't.

Checking scope before you paste the link

Before external reviewer access goes out, four things take about two minutes:

1. Run prj status and read it. Confirm nothing unexpected is queued, especially after a messy week of local experiments.
2. Open .prjcontext/memory/ in the browser view and skim for half-finished entries, internal nicknames, client names, vendor complaints, and cost numbers.
3. Open .prjcontext/sessions/ and check which transcripts are actually in there. A session you kept for debugging value may contain a long detour you'd rather not publish.
4. Check the instruction files for internal rules that only make sense inside the team, such as where credentials live or which staging box belongs to whom.

If the repository is going public, do all four with more suspicion, because memory and sessions become readable to anyone and the repository appears on Explore.

When a link isn't enough, and when it's too much

A reviewer answering "is this approach reasonable?" is well served by the browser: version diffs plus the decisions file usually answer the question without them running anything. A contributor who will write code needs the clone, as reader if you'll take patches another way, as writer if they'll push versions back. That handoff looks a lot like the team case in sharing AI coding context with your team, minus the shared assumptions.

The case with no clean answer is the client who should see output but not reasoning. There are no per-folder permissions, so hoping they don't click into sessions/ is not a control. The honest option is a separate repository containing only what you intend to show, pushed deliberately. If you want to see exactly what a recipient lands on, the getting-started guide walks through pushing a project and opening the result in the browser yourself.