Echo the Marker Before You Edit

I do not trust an assistant in the first fifteen minutes until it can echo a marker I just wrote into the tree. A lively chat only proves that tokens can travel, which is a different question from whether this workspace is the one under discussion. If the marker never comes back, I stop the session and fix visibility before I ask for a single change. Would you keep driving if the mirror showed a street you do not recognize at all?

The first quarter hour usually fails in a quiet way, not with a dramatic crash you can screenshot for a teammate. You authenticate, pick a model, watch a spinner settle, and then paste a paragraph about a refactor you have been avoiding. The reply sounds confident and names a few files, yet it still misses the function that actually hurts. That miss usually means the tool is staring at a sample repo, a parent directory, or yesterday's checkout instead of this one.

I treat that miss as a visibility failure, not as a prompt that needs one more adjective and a second try. Another attempt only spends the session on a conversation that cannot see the code you actually care about. The one fix I keep is smaller than a new prompt template and ruder than most setup guides admit. Would you hire a contractor to remodel a kitchen they have not been shown how to enter?

The fix is a marker probe that runs before the first real request and refuses to continue when the echo is wrong or missing. I drop a tiny file into the working tree and fill it with a random token that training data could not have memorized. Then I ask the assistant to read that one file and repeat the token, with no advice and no edits attached. If the token comes back intact, I know this session can see this tree, and only then do I allow a change.

Think of the marker as a coat check ticket rather than a unit test for the product you are building. The attendant does not need to understand your coat, and the assistant does not need your architecture either. The only job is to hand the same ticket back, and a wrong ticket means you are standing at the wrong counter. Why would I let a stranger hem the sleeves before they can read the number printed on the stub?

The script below is a local proposal you can run, and I am not reporting a benchmark, a quota, or a lab result. It refuses to start outside a git work tree, writes a short random token, and prints a prompt that forbids edits. I try to keep the probe directory out of history when the ignore file is writable, so a passed check does not become junk. If your policy forbids even a scratch file, skip the script and do not weaken that rule just to watch a demo.

#!/usr/bin/env bash
# visibility-probe.sh — local proposal, not a measured benchmark.
set -euo pipefail

root="$(git rev-parse --show-toplevel 2>/dev/null || true)"
if [[ -z "${root}" ]]; then
  echo "FAIL: not inside a git work tree"
  exit 2
fi

cd "${root}"
probe="${root}/.visibility-probe"
mkdir -p "${probe}"

if command -v openssl >/dev/null 2>&1; then
  token="$(openssl rand -hex 8)"
else
  token="$(od -An -N8 -tx1 /dev/urandom | tr -d ' \n')"
fi

printf '%s\n' "${token}" > "${probe}/MARKER"

if [[ -w "${root}/.gitignore" || ! -e "${root}/.gitignore" ]]; then
  if ! grep -qxF '.visibility-probe/' "${root}/.gitignore" 2>/dev/null; then
    printf '%s\n' '.visibility-probe/' >> "${root}/.gitignore"
  fi
fi

echo "cwd=${root}"
echo "marker_file=${probe}/MARKER"
echo "expected_token=${token}"
echo "Accept no edit until the echo check prints PASS."
cat <<'EOF'
Read only .visibility-probe/MARKER from the repository root.
Reply with the single token in that file and no other words.
Do not edit files. Do not explain the token. Do not propose a refactor.
EOF

After the assistant replies, I pipe that reply into a second command that compares it with the file on disk. A match is not a celebration, and a mismatch is not a mystery I solve by rephrasing the question in a longer voice. The checker strips whitespace so a trailing newline cannot fake a different workspace and push me to ignore later probes. What would you gain by negotiating with a reply that cannot repeat sixteen hex characters sitting in plain sight?

#!/usr/bin/env bash
# check-echo.sh — usage: pbpaste | ./check-echo.sh
set -euo pipefail

root="$(git rev-parse --show-toplevel)"
expected="$(tr -d '[:space:]' < "${root}/.visibility-probe/MARKER")"
got="$(tr -d '[:space:]')"

if [[ -n "${expected}" && "${got}" == "${expected}" ]]; then
  echo "PASS: marker echoed; this session can see this tree"
  exit 0
fi

echo "FAIL: expected [${expected}] but received [${got}]"
echo "Stop. Fix the folder mount before you request an edit."
exit 1

I run those two commands in order, and I read a FAIL line before I touch the original request again. On Linux I replace pbpaste with xclip reading the clipboard, because the probe should fit the machine I already trust. A PASS only means I may ask for one small change in a named file, and I still review the diff before I commit. Have you ever debugged a suggestion for ten minutes and then learned the tool was describing a sibling directory?

chmod +x visibility-probe.sh check-echo.sh
./visibility-probe.sh
# Copy the printed prompt into the assistant, then pipe only its reply.
pbpaste | ./check-echo.sh
# Linux alternative:
# xclip -selection clipboard -o | ./check-echo.sh

When the check fails, I do not open a second chat and hope, because luck is not a mounting strategy. I print the working directory, confirm the marker file still exists, and compare its contents with the string I thought I sent. Then I check whether the assistant was attached to a parent folder, a container path, or a sample that shares my project name. If those three glances still do not explain the miss, I stop rather than teaching myself that a blind session is normal.

When the echo should happen in a hosted room, I use MonkeyCode's free model access and its free server option for that single try. Disclosure: This article was prepared as part of MonkeyCode's product outreach. I am leaning on those two availability facts only, not on names, allotments, hardware, or a promise that the offer stays forever. Run the probe there if that room is simplest, read PASS or FAIL yourself, and do not let the room decide what done means.

The probe has sharp edges, and I would rather name them than let a green PASS travel further than it deserves. An echoed token shows that this session can read that one file, not that every path is visible and not that writes will land. It will not catch a reply that repeats the marker and then invents an edit in a file it never opened. Anyone who needs a reviewed production change, an air-gapped process, or a ban on scratch files should skip this shortcut.

I also refuse to hide secrets in the marker, because a hosted model may log whatever string you ask it to repeat. Use random output from openssl or any other non-secret string, then delete the probe directory when the session ends. If the ignore append fails because the ignore file is read-only, remove the marker yourself before you commit anything. Does a fifteen-minute win still count if you spend the evening scrubbing a token out of the remote history?

If the echo passes, my next message stays boring on purpose: one named file, one failing command, and only the change that command needs. I do not ask for a tour or a redesign while the session is young, because the marker only bought specificity. You can delete the chat once the diff is saved or once the check fails, so those first minutes never turn into a diary. Is there a better use of a fresh session than proving it can see the file before it is allowed to touch one?