The agent quoted a test I already deleted. I asked where that deleted file still lived. The working tree and the chat disagreed hard. Which memory was lying to me this time? That mismatch is the point of this article. A free model makes that confusion much louder. I keep mixing four stores into one story. The chat feels like a computer, but it is not. The box is a computer; the model is not. Four stores, not one brain Name them before the myths start flying around. If you skip this map, every myth wins. I use ugly names so I cannot blur them. Chat context: tokens sitting in this conversation Process env: one shell, one PID, then gone Box disk: files under the working directory Git objects: blobs that survived git add I needed a throwaway box for the checks. Disclosure: This article was prepared as part of MonkeyCode's product outreach. MonkeyCode offers free model access and a free server option. I use that pair only as a lab, not production. I am not claiming hardware, quotas, or model names. Those details change and I will not invent them. Myth 1: A new chat starts from a clean disk The model greets you like a blank machine. Did the previous shell leave files behind anyway? Disk does not reset because you clicked New. I look at three commands before I believe it. pwd ls -la git status --short If pwd still shows the old clone, disk remembered. The chat did not remember that leftover tree. Treat those two observations as different facts. Stop thanking the model for a leftover tree. A new chat is new tokens, not a new filesystem. Ask the box, not the greeting, what still exists. Myth 2: export is how you persist config I still see agents save keys with export. Then the next shell comes up empty again. Was that variable ever actually a file? export CANARY=1 bash -lc 'echo CANARY=${CANARY-missing}' The inner shell should print missing here, always. Process env dies with that process immediately. Write a file if you needed a file. Do not put secrets on a shared box. This FAQ is about classification, not secret storage. If it must persist, use a local secret manager. Myth 3: If the model quoted it, the file exists The chat pastes a perfect copy of utils.py. So the file must exist on disk, right? A quote is not proof of bytes. test -f utils.py && echo on-disk || echo missing git status --short -- utils.py Context can hold text the disk never wrote. Ask test -f before you celebrate anything. Then ask git, which is a fourth store. The model is a parrot with a toolbelt. Parrots quote, disks store, and git versions. Do not let a quote skip those two checks. Myth 4: Deleting in chat deletes on disk The agent says it removed the flaky test. You feel cleaner after that confident little sentence. The suite can still execute the old case. rg -n "flaky_case" tests || true git grep -n "flaky_case" || true ls -la tests Talk is not unlink, no matter the wording. Only rm unlinks; chat remains only talk. Confirm with ls after every destructive claim. I also check the editor buffer against disk. Unsaved text is a fifth place to get fooled. This article stops at four on purpose. Myth 5: The free model and free server share memory This is the one I still catch myself believing. One tab does not mean one shared brain. Inference is not the filesystem, even when adjacent. The model cannot stat unless a tool runs. The server cannot finish your sentence for you. They meet only through tools you actually invoke. Treat them as two machines with a pipe. The pipe is tool calls, not telepathy. If no tool ran, no disk fact moved. Want a receipt for the last mutation? Log the tool calls beside pwd and ls. No tool call means no new disk fact. A fluent denial is still only chat context. Do not promote it into a filesystem event. Bonus gotcha: cwd is not $HOME Agents cd and then describe files from memory. Your next command might start in a different directory. Relative paths lie hard when cwd moved. echo "cwd=$(pwd)" echo "home=$HOME" readlink -f . If those three lines disagree with the model, stop. The model is painting a directory it does not occupy. Fix cwd before you debate whether a file exists. A reconstructed session This is a reconstructed example, not a customer story. I am not inventing a company or a metric. Watch the four stores swap clothes anyway. Turn 1: the agent writes retry_helper.py in chat. No tool call ran, so disk still lacks the file. I still felt like the patch had landed. Turn 2: the agent runs tests on the box. The test file imports retry_helper with no mercy. Python then says there is no such file. Turn 3: the agent writes the file for real. test -f retry_helper.py now prints on-disk. Git still shows that path as untracked. Turn 4: I open a new chat on the same box. The model denies that the file exists. A local ls still lists the same file. That sequence is the FAQ in motion. Every myth above appears in those four turns. I now refuse to score a turn without the script. Artifact: persist_audit.sh Label this as a proposed local workflow. I have not sold you a benchmark here. Copy it onto a throwaway box and run it. #!/usr/bin/env bash # persist_audit.sh — proposed four-layer state audit # Run from a throwaway clone. Not a secret scanner. set -euo pipefail stamp="$(date -u +%Y%m%dT%H%M%SZ)" canary=".persist_canary_${stamp}" echo "canary=${stamp}" > "${canary}" echo "=== 1. chat reminder ===" echo "Ask the model: what is in ${canary}?" echo "Do not trust the answer without layer 3." echo "=== 2. process env ===" echo "PARENT_CANARY=${PARENT_CANARY-unset}" bash -lc 'echo CHILD_CANARY=${PARENT_CANARY-unset}' echo "=== 3. box disk ===" pwd ls -la "${canary}" test -f "${canary}" && echo "disk: present" || echo "disk: missing" echo "=== 4. git objects ===" git rev-parse --is-inside-work-tree git status --short -- "${canary}" git log -1 --oneline 2>/dev/null || echo "no commits" echo "=== classify ===" echo "context: only if the model quoted ${stamp} without tools" echo "env: only if PARENT_CANARY survived a child shell" echo "disk: ${canary} exists" echo "git: git status is not ?? after add and commit" Run it once before you trust a cleanup story. Then run it after every destructive claim. The script is the artifact; the chat is commentary. Here is the same idea in a tiny Python helper. It cannot see chat context, and that is the point. If a function cannot print chat, do not invent it. # proposed classifier — unexecuted example, not a benchmark from pathlib import Path import os import subprocess def classify(path: str) -> dict: p = Path(path) git = subprocess.run( ["git", "ls-files", "--error-unmatch", path], capture_output=True, text=True, ) return { "disk": p.is_file(), "env": path in os.environ, # paths are not env vars "git": git.returncode == 0, "chat": "unknown — ask a tool, not the model", } if __name__ == "__main__": print(classify(".persist_canary_demo")) Ten-minute drill Start a shell on the throwaway box. Save the script as persist_audit.sh and run it. Open a new agent chat against the same box. Ask what the canary file contains, exactly. Demand a tool cat before you accept any quote. Ask the agent to delete the canary in chat. Re-run test -f in your own shell. Commit only if you meant git to remember. Do the drill twice if the first pass felt obvious. The second pass is where myth five usually appears. New chat, same disk. Write that on a sticky note. Decision table Heard in chat Command that settles it New chat New shell Git quoted file tool cat plus test -f maybe no unknown export FOO=bar bash -lc 'printf %s "$FOO"' no no no wrote a file test -f path yes, same box yes after add committed blob git show HEAD:path yes yes yes Read the table left to right, never right to left. Chat is the least durable column on purpose. Git is the only column I will ship. What this workflow is not It is not a security audit of anyone's cloud. It is not a proof that free compute is durable. It is not CI, and it will not replace CI. Provider images differ, and I will not pretend otherwise. Do not store production secrets on a shared lab box. Do not treat leftover disk as a backup system. Free servers can be reclaimed without a speech. I will not guess when that happens. If you need durability, you need your own remote. Who should skip this Skip it if you already separate these four stores. Skip it if your agents cannot run shell tools. Skip it if you need guaranteed multi-day persistence. Also skip it for regulated data, full stop. A free lab box is the wrong place for that. Keep those workloads on machines you actually control. Closing I still catch myth five when I am tired. The tab looks unified, but the stores are not. Which layer just answered you right now? Run the script once on a throwaway clone. Then distrust every claim that skipped it.