FAQ: Five Myths About Agent CWD and Leftover Disk

When the agent says it patched ./src, whose ./src was that?
Did you print hostname in that shell today?
I keep hearing the same five claims in reviews.

They sound harmless. They are not.
A remote cwd is not your laptop cwd.
A finished prompt is not a clean disk.

This FAQ is a checklist you can run.
It is not a vibe, and it is not a benchmark.
No paid GPU is required for any step.

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

MonkeyCode shows up once, later, as a free remote half.
The checks still work on any throwaway box you already have.

Why these myths spread

Agents now edit, install, and test on a machine you do not own.
The chat looks local. The disk is not.
Have you compared pwd on both sides this week?

If you have not, you are guessing.
Guessing is how stale .venv trees become “green.”
Guessing is how yesterday’s build flags infect today.

I am not talking about model sampling here.
I am talking about the computer under the prompt.
Those are different problems. Treat them that way.

The artifact: a cwd identity receipt

Do not trust the recap paragraph.
Print a receipt from the shell the agent used.
Keep that file next to the patch.

Label: this is a procedure you run.
It is not a result I already measured.
I am not publishing fake timings.

#!/usr/bin/env bash
# cwd_receipt.sh — run inside the agent's shell
set -euo pipefail

out="${1:-cwd_receipt.txt}"
{
  echo "=== cwd identity receipt ==="
  echo "date_utc: $(date -u +%Y-%m-%dT%H:%M:%SZ)"
  echo "hostname: $(hostname)"
  echo "whoami: $(whoami)"
  echo "pwd: $(pwd)"
  echo "uname: $(uname -a)"
  echo "id: $(id)"
  echo "shell: ${SHELL:-unknown}"
  echo "path_head: $(echo "$PATH" | tr ':' '\n' | head -n 8)"
  echo "python: $(command -v python3 2>/dev/null || true) $(python3 -V 2>/dev/null || true)"
  echo "node: $(command -v node 2>/dev/null || true) $(node -v 2>/dev/null || true)"
  echo "=== leftover caches ==="
  ls -ld .venv node_modules dist build __pycache__ .pytest_cache 2>/dev/null || true
  echo "=== sentinel ==="
  if [ -f .agent_sentinel ]; then
    echo "sentinel_exists: yes"
    cat .agent_sentinel
  else
    echo "sentinel_exists: no"
  fi
} > "$out"

echo "wrote $out"
command -v sha256sum >/dev/null && sha256sum "$out" || shasum -a 256 "$out"

Run it on the remote shell. Run it on your laptop.
Then diff the two files. That diff is the lesson.

chmod +x cwd_receipt.sh
./cwd_receipt.sh remote_receipt.txt
# later, on your laptop
./cwd_receipt.sh laptop_receipt.txt
diff -u laptop_receipt.txt remote_receipt.txt || true

Four lines matter first: hostname, whoami, pwd, interpreter versions.
If those disagree, stop calling the box localhost.
Everything after that is detail.

Myth 1: A new prompt means a new disk

Claim people repeat: “I opened a new chat, so the workspace is clean.”

Why it sounds right: chats feel like sessions.
On a laptop, a session often maps to one checkout.
A remote agent box does not owe you that mapping.

What can you actually check?

• Does pwd match the path you expected?
• Do .venv or node_modules already exist?
• Is .agent_sentinel still sitting there?

pwd
ls -la
find . -maxdepth 2 \( -name node_modules -o -name .venv -o -name dist \)
cat .agent_sentinel 2>/dev/null || echo "no sentinel yet"

Write a sentinel before you trust anything.

echo "sentinel-$(date -u +%Y%m%dT%H%M%SZ)-$$" > .agent_sentinel
cat .agent_sentinel

Corrected model: the chat is a conversation.
The disk is a durable, maybe-shared tree.
Prompt boundaries are not filesystem boundaries.

If yesterday’s sentinel is still there, yesterday’s state is too.
Would you reuse a dirty /tmp on purpose?
Then do not reuse a dirty agent cwd by accident.

Myth 2: The remote PATH is your PATH

Claim people repeat: “It ran python, so it used my Python.”

Why it sounds right: the binary name matches.
Names are not versions. Names are not modules.
python3 on a free server can be a different world.

What can you actually check?

command -v python3
python3 -V
python3 -c "import sys; print(sys.executable); print(sys.version)"
command -v node
node -v
which pip pip3 npm pnpm 2>/dev/null || true
echo "$PATH" | tr ':' '\n'

Now run the same block on your laptop.
Do the version strings match? Do the paths match?
If not, a green remote test is a different runtime.

Corrected model: a command name is an alias into PATH.
PATH belongs to the box, not to the prompt.
Pin the interpreter in the receipt, not in memory.

I also want the shebang, not the story.

head -n 1 scripts/*.py scripts/*.sh 2>/dev/null || true

If the shebang points at /usr/bin/python3, whose file is that?
You do not know until python3 -V says so.
Ask the shell. Do not ask the chat.

Myth 3: Leftover caches make the next run “faster and true”

Claim people repeat: “Deps are already there, so we can skip install.”

Why it sounds right: local muscle memory.
Warm caches feel like competence.
On a remote box they often belong to another run.

What can you actually check?

ls -ld .venv node_modules __pycache__ .pytest_cache .mypy_cache 2>/dev/null
stat .venv node_modules 2>/dev/null || true

If those directories predate this prompt, they are suspects.
A warm cache can hide a broken lockfile.
A warm cache can hide a missing native wheel.

Corrected model: a cache is an environment side effect.
It is not part of the patch.
The patch is source plus lockfile, nothing else.

Decision table I keep above the keyboard:

Remote symptom	Treat as the patch?	Do this instead
Agent skipped install, cache present	No	Delete cache, install from lockfile
Interpreter version differs from laptop	No	Re-run on a matching runtime
pwd is not the repo you named	No	Stop. Recheck cwd before any edit
Sentinel from an older chat remains	No	Assume dirty disk; copy out only source
Receipts match on host, cwd, versions	Maybe	Still re-run tests on your laptop
No receipt at all	No	Refuse the patch until one exists

Would you merge a PR because node_modules already existed?
Then do not merge because the agent “did not need install.”

Myth 4: Closing the tab wipes the remote workspace

Claim people repeat: “I closed the chat, so nothing remains.”

Why it sounds right: browser tabs are ephemeral.
Disks are not.
A free remote server may keep the tree.
It may also wipe the tree without warning.

I will not invent retention days.
I do not know how long any free server keeps files.
That uncertainty is the actual policy.

Check it with a sentinel, not with hope.

echo "keep-me-$(date -u +%Y%m%dT%H%M%SZ)" > /tmp/agent_sentinel.txt
cp /tmp/agent_sentinel.txt .agent_sentinel
pwd > /tmp/agent_pwd.txt

Later, in a new session on the same server option:

cat /tmp/agent_sentinel.txt 2>/dev/null || echo "tmp sentinel gone"
cat .agent_sentinel 2>/dev/null || echo "repo sentinel gone"
cat /tmp/agent_pwd.txt 2>/dev/null || echo "pwd note gone"

Two outcomes, both useful.
If it remains, you have stale-state risk.
If it is gone, you have lost-work risk.

Corrected model: chat lifetime is not disk lifetime.
Plan for hostile-or-amnesiac storage.
Copy out the source you care about before you close anything.

Did you paste an .env into that shell?
Rotate those values. Do not debate the point.

Myth 5: “It worked on the free server” means it works here

Claim people repeat: “Remote was green, so local will be green.”

Why it sounds right: same repo name, same tests.
Repo names travel. Kernels do not.
libc does not. Case-sensitive filesystems do not.

What can you actually check after the agent stops?

1. Save remote_receipt.txt.
2. Copy only the source you intend to keep.
3. Recreate the tree on your laptop from that source.
4. Run cwd_receipt.sh locally.
5. Diff the receipts.
6. Run the same test command locally.

# after you have the source on your laptop
./cwd_receipt.sh laptop_receipt.txt
diff -u remote_receipt.txt laptop_receipt.txt || true
# then the project’s real test command, not the chat summary

If hostname differs, good. That is expected.
If Python or Node differs, the green remote run is a different experiment.
If pwd layout differs, you tested another tree.

Corrected model: a remote pass is evidence about that box.
It is not evidence about your laptop.
It is not evidence about CI.
Promote the result only after the receipt and the tests both travel.

A workflow template, not a war story

Label: proposed workflow. I am not selling an SLA.

1. Open the remote shell before any code prompt.
2. Run cwd_receipt.sh and keep the file.
3. Write .agent_sentinel with a unique string.
4. Restrict edits to that cwd only.
5. Run the receipt again after the agent stops.
6. Diff the two remote receipts for surprise files.
7. Copy source out. Leave caches behind.
8. Recreate the tree on your laptop.
9. Run the laptop receipt and the real tests.
10. Only then open the PR.

Need a throwaway remote shell for steps 1–6?
MonkeyCode offers free model access and a free server option, which can be that remote half if you do not already have a disposable box.
Skip the product if you have a VM.
The receipt still matters on a VM you own.

What this does not prove

The receipt does not prove the model is smart.
It does not prove the tests are complete.
It does not prove the free server still exists tomorrow.
It does not prove your secrets stayed off that disk.

Also missing from the default script:

• outbound network from the server
• whether sudo exists
• whether the clock is honest
• whether two jobs share a uid
• case sensitivity of the filesystem

Need those answers? Add them to the receipt.
Do not import laptop defaults onto a stranger’s box.

# optional extras, still not a full audit
date -u
umask
mount | head
df -h .
python3 -c "import os; print('case_ok', os.path.exists('README.md') != os.path.exists('readme.md') or True)"

Those lines are probes. They are not certificates.

Who should not use this approach

Skip this if hermetic CI is already your only merge gate.
Skip this if you cannot run a shell at all.
Without a shell, you cannot verify cwd.

Do not use a free remote server for:

• customer data
• private keys
• production credentials
• anything you cannot rotate tonight

A free server is for throwaway identity checks.
It is not your laptop.
It is not your CI.
It is not your vault.

If the work is production-shaped, use a box you control.
If the work is secret-shaped, do not put it on a free disk.
That is not caution theater. That is basic hygiene.

Limitations

Short sentences do not make a proof.
This FAQ is a mental model plus a script.
Platforms change. Disks get wiped. PATH mutates.

I did not drop latency charts here on purpose.
Any number I invented would be stale tomorrow.
Run the receipt on the boxes you actually have.

If sha256sum is missing, use shasum -a 256.
If hostname is missing, you are already in trouble.
If you cannot write .agent_sentinel, you do not own the cwd.

Closing questions

So, can you trust a remote agent workspace?
Only after hostname, cwd, and interpreters are explicit.
Only after leftover caches are treated as hostile.
Only after the tab is not confused with the disk.

Print the hostname.
Hash the receipt.
Diff remote against laptop.
Then we can talk about the patch.