Did the agent host just stamp your tests green?
Was that host your laptop or a shared box?
Those two machines are not the same computer.
I keep hearing the same four claims.
Those claims sound harmless, yet they waste hours.
This FAQ offers a corrected mental model.
I will not sell a miracle workflow here.
I will sell a fingerprint you can rerun.
Copy the script, then compare three environments.
Why this FAQ exists
Agents now edit files on remote hosts daily.
Free model access makes that loop practical.
A free server option makes hosts feel disposable.
Does disposable mean identical to your laptop?
Does a green log mean CI will agree?
I want receipts from shells, not vibes.
Three hosts can disagree without anyone lying.
These checks also fit MonkeyCode's free remote server option.
Disclosure: This article was prepared as part of MonkeyCode's product outreach.
The same checks also fit free model access there.
The product is optional for this method.
The fingerprint still works on any SSH box.
Remove the product name and the checklist remains.
Myth 1: A green agent host means a green laptop
You saw pytest pass in the agent transcript.
You merged, and your laptop failed on import.
What changed between those two shells today?
Plenty can change without anyone lying here.
Python versions drift across hosts without warning.
Optional extras go missing on one side.
The corrected model is simple and strict.
Treat every host as a foreign machine.
Trust a result only after fingerprints match.
Proposed check, labeled unexecuted
Label this as a proposed local command.
I am not quoting a private benchmark here.
python3 --version
which python3
printf '%s\n' "$PWD"
git rev-parse --short HEAD 2>/dev/null || printf '%s\n' 'no-git'
Run that block on your laptop first.
Run it inside the agent host shell.
Diff the four lines before trusting tests.
Myth 2: Ending the chat wipes the host
Did you close the thread and then relax?
Did a leftover server keep the port bound?
Chat lifetime is not process lifetime here.
I see this myth after every rushed demo.
The reply finished, but the socket remained.
Tomorrow's agent binds against a dead port.
The corrected model is an operations model.
The host is a long-lived workspace process.
The chat is only a short-lived driver.
Proposed process audit
This block is a proposed audit, not evidence.
Run it before you start the next session.
ss -ltnp 2>/dev/null || netstat -ltnp
ps aux | awk 'NR==1 || /python|node|uvicorn|pytest/'
Kill the processes that your session started.
Record the PID in a small file.
Do not assume the next chat starts clean.
Why does this leftover process keep surprising people?
Because the UI looks like a fresh room.
The kernel still owns yesterday's child processes.
Myth 3: The model already sees the whole box
The agent wrote a smart summary of disk.
So it must have read the filesystem, right?
Context windows are not mounted filesystems though.
Tools remain the only eyes it has.
If nobody called find, then it guessed.
Guesses look fluent, and they still miss files.
The corrected model is strictly tool-shaped.
No tool call means no real observation.
Ask for a listing, then a content hash.
Proposed observation, not a vibe
find . -type f -not -path './.git/*' | sort | head -n 50
sha256sum pyproject.toml requirements.txt 2>/dev/null || true
Did the agent paste this command output?
Or did it narrate a likely project tree?
Narration is not a directory listing at all.
Myth 4: A free remote host is close enough for CI
CI images pin compilers, runtimes, and lockfiles.
A free host is a convenience sandbox only.
Those jobs optimize for very different things.
Can you deploy from a convenience sandbox?
Should secrets ever land on that box?
I would not put production keys there.
The corrected model splits three separate planes.
Your laptop is for interactive reproduction work.
CI remains the only merge gate that counts.
The agent host is only a scratch editor.
Decision table
When someone recites a green result, pause.
Map the claim onto this table first.
| Claim you heard | Trust it now? | Replay where |
|---|---|---|
| The agent said tests passed | No | Laptop, then CI |
| Fingerprints match on three hosts | Closer | Still run CI |
| Lockfile hash matches the CI checkout | Better | CI stays source of truth |
| Secrets were pasted into the chat | Never | Rotate, then rebuild |
A match across rows still is not production.
It only means you earned a fair rerun.
Artifact: workspace_fingerprint.py
This helper is proposed, not a lab result.
Save it as workspace_fingerprint.py in the repo.
Run it in each environment you actually trust.
#!/usr/bin/env python3
"""Fingerprint a workspace. Do not print secret values."""
from __future__ import annotations
import hashlib
import os
import platform
import subprocess
import sys
from pathlib import Path
INTERESTING_FILES = (
"requirements.txt",
"pyproject.toml",
"package-lock.json",
"pnpm-lock.yaml",
"go.sum",
"Cargo.lock",
)
def sha256_file(path: Path) -> str:
digest = hashlib.sha256()
with path.open("rb") as handle:
for chunk in iter(lambda: handle.read(65536), b""):
digest.update(chunk)
return digest.hexdigest()[:16]
def git_head() -> str:
try:
out = subprocess.check_output(
["git", "rev-parse", "HEAD"],
stderr=subprocess.DEVNULL,
text=True,
)
return out.strip()[:12]
except (OSError, subprocess.CalledProcessError):
return "no-git"
def env_names_hash() -> str:
names = sorted(os.environ)
blob = "\n".join(names).encode("utf-8")
return hashlib.sha256(blob).hexdigest()[:16]
def lock_hashes() -> dict[str, str]:
found: dict[str, str] = {}
for name in INTERESTING_FILES:
path = Path(name)
if path.is_file():
found[name] = sha256_file(path)
return found
def main() -> None:
print("python", sys.version.split()[0])
print("platform", platform.platform())
print("cwd", Path.cwd())
print("git", git_head())
print("env_names", env_names_hash())
locks = lock_hashes()
if not locks:
print("locks none")
return
for name, digest in locks.items():
print("lock", name, digest)
if __name__ == "__main__":
main()
Redirect stdout into one file per host.
Keep the files beside your replay script.
python3 workspace_fingerprint.py | tee /tmp/fp-laptop.txt
python3 workspace_fingerprint.py | tee /tmp/fp-agent-host.txt
diff -u /tmp/fp-laptop.txt /tmp/fp-agent-host.txt
No diff yet means you are not done.
Run the same test command after the diff.
Matching fingerprints only buy you a fair race.
How to read a mismatch
Do you see different Python versions in the files?
Recreate the virtualenv from the lockfile immediately.
Do not debug application code before that step.
Does the lock hash differ across two hosts?
Then you are not testing the same dependencies.
Sync the lockfile, then rerun the fingerprint.
Does env_names disagree while the SHA matches?
A required variable is missing on one host.
Compare names only, and never print secret values.
Does cwd point at a different checkout path?
Tests may have loaded the wrong local package.
Change into the repo root and fingerprint again.
Does git head differ in the two files?
You replayed the wrong revision by accident.
Check out the SHA from the agent host.
A concrete replay workflow
Follow this order, and do not skip diffs.
- First, freeze the branch SHA on the agent host.
- Run
workspace_fingerprint.pyon that same host. - Copy the fingerprint file onto your laptop.
- Check out the same SHA on the laptop.
- Run the fingerprint script again locally.
- Diff both files, then stop on lockfile drift.
- Replay the exact test command, flags included.
- Open CI on that SHA only after local green.
What counts as the exact test command here?
Write the argv down in a tiny script.
Do not let the model paraphrase the flags.
A pytest file path with flags is a command.
Saying you ran billing tests is only a story.
Capture the command, not the vibe
printf '%s\n' 'pytest -q tests/test_billing.py' > /tmp/replay.sh
chmod +x /tmp/replay.sh
/tmp/replay.sh
printf 'exit:%s\n' "$?"
Store replay.sh next to the fingerprint file.
Future you will need those exact flags.
The agent will not remember them later.
What this method does not cover
It does not prove production correctness at all.
It does not replace a pinned CI image.
It does not make a free host hermetic.
It will not catch flaky tests by itself.
It will not hash secret values on purpose.
If you need secret parity, you already lost isolation.
Who should skip this whole approach today?
Skip it if you have no tests to replay.
Skip it if the host holds customer data.
Skip it if you cannot copy a SHA around.
Do not paste dotenv files into the chat.
Do not treat scratch disks as real backups.
Do not merge because a transcript looked confident.
A better default question
Ask this before you trust a green log.
Which host ran that command, on which SHA?
If nobody can answer, the result is trivia.
I still use cheap model loops for edits.
I still like a disposable remote workspace too.
I just refuse to confuse it with CI.
If you already have free model access, good.
Pair it with a host fingerprint, not hope.
That is the whole FAQ, start to finish.
Top comments (0)