FAQ: Five Myths About the Agent's Copy of Your Repo

Which clone did the agent actually edit tonight?
I ask this every time a free box looks helpful.
My laptop has a repo, and the box has another.

The model has a third thing: a prompt window.
Those three are not the same machine.
They do not share memory, disk, or git index.

Yet most of us talk like they do.
That habit ships empty commits and missing lockfiles.
It also drops secrets into the wrong process.

Why this FAQ exists

Free models made agent loops cheap to start.
Free servers made those loops leave the laptop.
That split created a new class of myths.

People repeat them in standups and in PR comments.
I keep a short FAQ for myself now.
It is not a pitch, just a map of state.

I reproduce these checks on a free remote server when I have one.
MonkeyCode offers free model access and a free server option.
That pairing is enough to trigger every myth below.

Disclosure: This article was prepared as part of MonkeyCode's product outreach.

The four places "the repo" can live

Do not say "the repo" without a location.
I force myself to pick one of these:

• Model context: tokens in this turn only
• Box disk: files under the remote working tree
• Box git: objects and index inside that tree
• Laptop git: the clone you will actually ship

If you cannot name the layer, you are guessing.
Guessing is how silent drift starts in a PR.

Myth 1: The model remembers the project between chats

The claim: "It already knows this codebase."

The corrected model: The model has this prompt, not a disk.

Did yesterday's thread survive into today's prompt tokens?
You do not know until you check the context.
A free model is not a wiki of your company.

I treat every new chat as amnesia with a shell.
The shell may still have files, while the model may not.
Those two facts can be true together.

Evidence check

Ask the agent for a file it never received.
Then open the same path on the box yourself.

# on the box
test -f src/legacy_tax.py && echo on_disk || echo missing
wc -l src/legacy_tax.py 2>/dev/null

If the file exists and the model shrugs, context lost.
If the model cites a missing file, it invented path memory.
Neither case means "the project is loaded."

So what do I ask the agent next?

1. "Quote the first line of src/legacy_tax.py."
2. Run head -n 1 src/legacy_tax.py myself.
3. Compare those two strings without charity.

Mismatch means I recap the file, or I stop.
I do not keep prompting through a memory fantasy.

Myth 2: The free server keeps files like a laptop

The claim: "Leave it. I will continue tomorrow."

The corrected model: Durability is a property you measure, not a vibe.

Is the workspace a cattle box or a pet laptop?
A free remote server is not your ~/src.
Do not assume sleep, disk, or home survive.

I snapshot a fingerprint before I walk away.
I snapshot again when I return to the box.
If they differ, the myth already cost me time.

Evidence check

Save the block below as clone_fingerprint.sh.
I label it a proposal until you run it.

#!/usr/bin/env bash
set -euo pipefail
echo "host=$(hostname 2>/dev/null || echo unknown)"
echo "pwd=$(pwd)"
echo "user=$(id -un)"
echo "date=$(date -u +%Y-%m-%dT%H:%M:%SZ)"
git rev-parse --show-toplevel
git rev-parse HEAD
git status --porcelain=v1
git diff --stat
git remote -v | sed 's/:[^/]*@/:[REDACTED]@/g'

Run it, save the output, and compare later with diff -u.
If hostname changed, you are on a new machine.
If HEAD moved without you, something else checked out.

Your box may deny hostname, and that is data too.
A denied syscall still beats a story in chat.

Myth 3: git status on the box is git status at home

The claim: "It is clean, so I am clean."

The corrected model: You are looking at a different index.

Two clones drift in boring, easy-to-miss ways.
One clone has a dirty lockfile, the other has an extra commit.
Neither clone will text you about the gap.

Does git status on the box describe your laptop?
Only if they share a filesystem, which they do not.

Evidence check

On each machine, print a one-line identity.

git rev-parse HEAD
git status -sb
git log -1 --format='%h %s'

Then compare the two lines side by side.
Same HEAD and same porcelain means you may proceed.
A different HEAD means you are reviewing the wrong clone.

An agent can "finish" a branch that never existed locally.
The chat can be honest about the box.
The laptop can still tell a completely different story.

Want a louder check than git status?

# proposed: fail if this clone is not the branch you named
expected="${1:?branch}"
got="$(git rev-parse --abbrev-ref HEAD)"
test "$got" = "$expected"
echo "branch_ok=$got"

Pass the branch name in, and do not trust the agent's label.
Labels live in context, but branches live in git.

Myth 4: A package install on the box updates your app

The claim: "It installed the dependency, we are good."

The corrected model: The lockfile you ship is the one in your clone.

npm install on the box mutates the box.
It does not teleport into your laptop.
CI will read the clone you push, not the box's node_modules.

Did the agent also commit the lockfile on that clone?
Did you actually fetch that commit at home?
If either answer is no, the install is a ghost.

Evidence check

On the box, after the agent "installs" something:

git status --porcelain package-lock.json pnpm-lock.yaml Cargo.lock go.sum
git diff --stat -- package-lock.json pnpm-lock.yaml Cargo.lock go.sum

Then, on the laptop:

git fetch --all --prune
git log --oneline HEAD..origin/HEAD
git diff HEAD -- package-lock.json pnpm-lock.yaml Cargo.lock go.sum

No lockfile diff in your shipping clone means the install stayed.
Your production build will not see those packages.

I also keep the install command in the PR body.
Was it npm i lodash or npm i lodash --save?
The transcript lies in the same way people do.

Myth 5: The free box is a fine home for real secrets

The claim: "It is my server, so .env is private."

The corrected model: Prompt, process env, and disk are three channels.

Did you paste the key into chat?
Then the model context already has that key.
Did you write .env on the box, so disk has it?

Did a tool print env into the transcript?
Now the session log has it too.
A free shared box is the wrong vault.

I do not put production tokens on exploratory boxes.
I use fake values and a deny-list.
The audit below prints names, never values.

Evidence check

# names only; do not cat secrets
printf 'env names:\n'
env | awk -F= '$1 ~ /(KEY|TOKEN|SECRET|PASSWORD|CREDENTIAL)/ {print $1}'

printf 'dotenv files:\n'
find . -name '.env*' -o -name '*.pem' | head

printf 'tracked accident:\n'
git ls-files | grep -E '\.env|id_rsa|\.pem$' || true

If a name appears, treat that channel as contaminated.
Rotate anything that was a real credential.
Then restart the loop without the secret.

Can the model "forget" a pasted key if I ask nicely?
No, you rotate, and you do not prompt-delete history.
Treat the transcript as another clone of the secret.

Artifact: a 15-minute clone audit

This is the workflow I actually run first.
It is a test plan, not a benchmark.

Step 1 — Name the four layers

Write them on paper if you must:

1. Context
2. Box disk
3. Box git
4. Laptop git

Ask one concrete question for each layer.
Do not skip a layer because the chat sounded sure.

Step 2 — Fingerprint both clones

Run the fingerprint script on the remote box.
Run the same script on the laptop.
Then diff the two fingerprint files side by side.

diff -u laptop.fp box.fp || true

Step 3 — Classify the drift

Use this table, and do not invent a fifth column.

Symptom	Layer that lied	What to do first
Agent cites a file test cannot open	Context vs disk	test -f, then recopy the path
File exists, git status is silent	Disk vs git	add it on purpose, or ignore it on purpose
Box HEAD is not laptop HEAD	Two gits	fetch, then choose a branch in writing
Lockfile dirty only on the box	Box git vs laptop git	commit on the box, then fetch at home
Secret name in env or .env	Process vs vault	rotate, then wipe the file

Step 4 — Make the laptop the gate

I do not merge from memory of a chat.
I fetch, read git show, and run tests I already trust.

git fetch origin
git show --stat FETCH_HEAD
# run your existing test command here

If the tests only passed on the box, that is another clone myth.
Re-run those tests where you ship from.

Optional: a tiny fingerprint diff helper

This is pseudocode I keep next to the shell script.
Run it only on the two text fingerprints.

# proposed helper: fingerprint_diff.py
from pathlib import Path

def load(path: str) -> dict[str, str]:
    out = {}
    for line in Path(path).read_text().splitlines():
        if "=" in line:
            k, v = line.split("=", 1)
            out[k.strip()] = v.strip()
        elif line.startswith("/"):
            out["toplevel"] = line.strip()
    return out

laptop = load("laptop.fp")
box = load("box.fp")
keys = sorted(set(laptop) | set(box))
for key in keys:
    left = laptop.get(key, "<missing>")
    right = box.get(key, "<missing>")
    mark = "OK" if left == right else "DRIFT"
    print(f"{mark:5} {key}: laptop={left!r} box={right!r}")

I care about host, HEAD, and dirty paths first.
Everything else in that file is commentary.

Limitations

This FAQ does not measure any model quality.
It does not claim quotas, uptime, or hardware.
I have no numbers to sell you.

The fingerprint lies if git is missing here.
It also lies if you run it in a submodule by accident.
find can miss ignored secret files with odd names.

Do not treat a free server as a compliance boundary.
Do not treat a free model as long-term memory.
Do not treat my table as a security audit.

The redaction sed is incomplete on weird remotes.
I still use it, then I refuse to print the raw URL.
I call that caution, not real cryptography.

Who should not use this approach

Skip the free-box loop if you handle production secrets.
Skip it if your policy forbids unknown remote disks.
Skip it if you cannot fetch the box's commits.

Also skip it if you need a durable pet machine.
This workflow assumes you will verify, then throw away.
Pets need backups, IAM, and a named owner.

If CI is already your only remote clone, start there.
The myths still apply, and the extra box is optional.

What I believe after the audit

The cheap loop is still useful to me.
The cheap loop is also a split-brain machine.
I will not collapse those two facts.

I keep three refusals on a sticky note:

• Context is not disk
• Disk is not git
• The box is not my laptop

Which clone are you about to review?
If you cannot answer, run the fingerprint first.
The chat can wait for that answer.

If you have a free remote box, run the audit on the next patch.
Then argue with the transcript, not with your memory of it.