A prj clone brings down four things: the source files that were pushed, the project instructions (CLAUDE.md, AGENTS.md, anything under .prjcontext/instructions/), the project memory in .prjcontext/memory/, and the AI coding sessions someone chose to keep in .prjcontext/sessions/. It does not bring your .env, your git history, your branches, your installed dependencies, or anything that was excluded at push time. That is the complete boundary, and it is worth knowing precisely before you clone a PrjLab project you did not push yourself.
The reason the question comes up at all is that "clone" arrives with git's meaning attached. With git you know exactly what you got: tracked files at a commit, plus history. Everything else, the environment file, the local database, the reasoning behind the weird retry loop, you get by asking a human. A PrjLab clone shifts that line, and if you are not sure where it sits now, you end up re-asking a teammate questions the clone already answered.
What you get when you clone a PrjLab project
Run prj clone handle/name and you land in a directory with two layers.
my-project/
├── src/
├── package.json
├── CLAUDE.md
├── AGENTS.md
└── .prjcontext/
├── instructions/
├── memory/
└── sessions/
Source files. Whatever was in the repository at the version you pulled. If the project pushed from a working tree that honoured .gitignore, you get the same set of files a collaborator would see in git, minus history. Build artefacts, node_modules, caches: not there, because they were skipped on the way up.
Project instructions. CLAUDE.md and AGENTS.md at the project root are recognised as instructions, and so is anything under .prjcontext/instructions/. This is the layer that saves you the most time on arrival, because it is the one you would otherwise reconstruct by guessing. Test command, lint rules, the directories the assistant is told to stay out of, the conventions the project actually uses rather than the ones its framework suggests. If a project keeps both files in sync rather than letting them drift apart, you can point any assistant at the same rules on the first run.
Project memory. Decisions, notes, open threads. The clone gives you the file; it does not give you a summary of it. Read it before you open an assistant session, because this is where you find out that SQLite was chosen deliberately, that server-sent events were tried and dropped in September, and that the migration script in scripts/ is half-finished on purpose. Projects that keep this layer honest usually follow something like the practice in project memory for AI coding.
Saved sessions. The conversations someone decided were worth keeping. Not every session, which matters: you are getting a curated set, so if a session is in there, somebody thought the reasoning in it would be needed again. These are files you read, not context that gets injected anywhere automatically. You open the one that matches what you are about to touch, skim the part where the approach was argued out, and leave the rest alone.
What a clone leaves out on purpose
The exclusions are as useful as the contents, because they tell you what you still owe the project.
| Not in the clone | Where it comes from |
|---|---|
.env and other secret files | Your own secret manager, or a teammate sending values out of band |
| Key files, credential folders | Same |
Anything in .gitignore / .prjignore | Regenerated or installed locally |
| Git history, branches, remotes | git clone from your git host |
| Installed dependencies, build output | Your install and build commands |
Secrets are absent for a specific reason: the CLI skips obvious ones at push time, so they were never uploaded. That is a safety net rather than a complete secret scanner, which is why the push side still involves reading prj status before sending anything. The receiving end of that discipline is what makes a clone safe to hand around, and the full picture is in keeping secrets out of your AI context. If you inherit a project and find an API key in a transcript, that is a push-side mistake to fix, not normal behaviour.
Git history is absent because PrjLab sits beside git, not instead of it. On a real handoff you will usually do both: git clone for the code history, prj clone for the context around it. The versions PrjLab keeps are its own, one immutable version per push, each one openable in the browser with a list of changes and a line diff against the previous version.
Checking what you inherited, before you write a line
Fifteen minutes of reading beats an afternoon of re-deriving. A reasonable order:
prj statusin the cloned directory, so you know what the tool sees locally.- Read the instruction file end to end. Note any rule that looks stale, since stale guardrails are worse than missing ones.
- Read memory newest entry first. Stop when entries stop affecting what you are about to do.
- List
.prjcontext/sessions/and open only what overlaps your task. - Then install, build, run the tests. If the test command in the instructions does not work, that is your first real finding and belongs in memory.
Before cloning at all, it is often faster to look at the repository in the browser, which shows you the three context folders and their contents without touching your disk. Browsing a project in the browser covers that side, and it is the usual way to decide whether a repository is worth pulling down.
From a working directory to a working session
A clone that only gives you files leaves you doing archaeology: reading code to infer intent, then explaining your inferences to a fresh assistant that will forget them. A project context clone shortens that to reading what someone already wrote down. The handoff still depends on the person who pushed, so a clone is only as good as the memory and instructions behind it, and the handoff note remains the cheapest thing a departing developer can leave.
We built prj clone to be one command because splitting it would mean one of the four layers gets forgotten, and the forgotten one is always memory. If you want to see what your own project looks like from the receiving end, push it once and clone it into a scratch directory; the getting-started guide covers both halves. The workflow for moving between your own machines, rather than between people, is in continuing an AI coding project on another machine.
Questions that come up
Does a prj clone include git history?
No. You get the files at the version you pulled, not commits, branches or remotes. Run git clone alongside it when you need history. The two tools cover different things and are meant to be used together.
Can someone clone my repository without being added to it?
Only if you make it public. Repositories are private by default and served only to current members, as a reader (view and clone) or a writer (also push). Removing access takes effect immediately. A public repository can be read and cloned by anyone at prjlab.com/handle/name and appears on Explore, including its memory and sessions, so read those before flipping the switch.
What happens if a clone or pull is interrupted?
Run it again. An interrupted push or pull completes rather than duplicating. On a repository you already have locally, prj pull will not overwrite your edits either: conflicting files get reported instead of replaced, so you decide what to do with them.
Will my assistant read the cloned context automatically?
It reads what it normally reads. Claude Code picks up CLAUDE.md, Codex and similar agents pick up AGENTS.md. Memory and sessions are files on disk, so you point the assistant at the relevant one or paste the part that matters. Nothing is injected on your behalf, which is why choosing which sessions to keep matters more than keeping all of them.
