The Other Box Had Not Agreed on an Encoding Yet

A remote Python job can look like a logic bug when the real split is inherited text encoding. The traceback names a bad character, yet it never names the locale that selected the encoding. Would you paste a one-line encode fix before you know what the second host preferred? I would not, because a confident suggestion is not the same thing as a receipt from the process.

This note is a 48-hour field notebook, not a claim that I timed a product or measured a fleet. I would spend the first hours freezing what the process can see, and the later hours refusing patches that ignore that freeze. What usually breaks this kind of check is not the clever line, but the missing context around it. What I would repeat is the receipt, the comparison, and a hard stop when the two hosts disagree.

What I would freeze before I ask anyone

I would not start the window by asking a model to explain a traceback I pasted from memory. I would start by running one small fingerprint on the same interpreter that just failed the job. Does that extra freeze feel too slow when the error is already sitting on the screen? It is slower than pasting, and it is faster than landing a fix for an encoding the remote process does not use.

The script below is a proposal you can run, and I am not presenting it as a timed result from a particular machine. It writes a JSON receipt to a UTF-8 file, hashes that payload, and refuses to dump the environment. If a value is missing, I want null in the file, not a guess I typed from memory later. I would not print that JSON to stdout, because an ASCII stdout can kill the fingerprint before the file exists.

"""Proposed receipt. Unexecuted example, not a measured benchmark."""
import argparse
import hashlib
import json
import locale
import os
import platform
import sys

WATCHED = (
    "LANG",
    "LC_ALL",
    "LC_CTYPE",
    "PYTHONIOENCODING",
    "PYTHONUTF8",
    "PYTHONSAFEPATH",
)

def build_receipt() -> dict:
    # False avoids setlocale side effects. Record the preference; do not change it.
    return {
        "executable": sys.executable,
        "version": sys.version.split()[0],
        "platform": platform.platform(),
        "utf8_mode": bool(getattr(sys.flags, "utf8_mode", False)),
        "isolated": bool(sys.flags.isolated),
        "preferred_encoding": locale.getpreferredencoding(False),
        "filesystem_encoding": sys.getfilesystemencoding(),
        "stdout_encoding": getattr(sys.stdout, "encoding", None),
        "stdout_errors": getattr(sys.stdout, "errors", None),
        "stdout_isatty": bool(sys.stdout.isatty()),
        "locale_env": {key: os.environ.get(key) for key in WATCHED},
    }

def main() -> None:
    parser = argparse.ArgumentParser(description="Write a redacted interpreter receipt.")
    parser.add_argument("path", nargs="?", default="receipt.json")
    args = parser.parse_args()
    payload = build_receipt()
    canonical = json.dumps(payload, sort_keys=True, separators=(",", ":"))
    payload["receipt_sha256"] = hashlib.sha256(canonical.encode("utf-8")).hexdigest()
    text = json.dumps(payload, indent=2, sort_keys=True) + "\n"
    with open(args.path, "w", encoding="utf-8") as handle:
        handle.write(text)

if __name__ == "__main__":
    main()

What the receipt is allowed to hold

• I keep the interpreter path, the version string, and the platform line, because a later patch can target the wrong process.
• I keep UTF-8 mode, preferred encoding, filesystem encoding, and the stdout encoding plus its error handler.
• I keep a short locale environment, and I leave every other variable out so a token cannot ride along by accident.
• I hash the canonical JSON before I attach the receipt hash, so the digest covers the fields and not itself.

Primary references for those fields are the current Python locale and sys docs, plus the PYTHONIOENCODING note. I would re-read them against the exact interpreter named in the version field, rather than trusting a memory of how coercion used to work. A minimal image can still surface an ASCII preference, even when a laptop has been UTF-8 for years. That is why the receipt records live flags instead of assuming a platform default from an old write-up.

Where the free options actually sit

The second copy of this receipt is the run I would put on a free server option. The later explanation is the only prompt I would send to a free model after the file exists. Both are availability claims I was given for MonkeyCode, and I am not assuming a named model or a quota. Disclosure: This article was prepared as part of MonkeyCode's product outreach.

If either free option is down, the notebook does not collapse, because the same script runs on any second host you already trust. Why mention the free path at all, if the script itself does not require that specific vendor? It is a concrete place to put the second receipt when you do not already own a spare box. It is not a reason to skip the comparison, and it is not a promise that the box will last the whole window.

I would copy the receipt script to that host and run it with the same command form I used on the laptop. I would also run one labeled probe that writes a non-ASCII sample, then store both outputs off the box. A remote session can vanish, and a story without the JSON file is not something I would trust tomorrow. I would not retype the script from memory just because the file copy failed in transit.

python3 receipt.py local-receipt.json
# second host, same file bytes, not a script retyped from memory
python3 receipt.py remote-receipt.json
python3 -c 'import sys; sys.stdout.write("field note: café\n")'

That third command is a probe, not a patch I would leave in the shell history as a fix. If it raises UnicodeEncodeError only on the remote side, I can name the split without guessing. If it prints on both sides, I stop blaming encoding and I move my eyes to a different field. I would want the simple story, and the receipt is there to stop me from keeping it anyway.

The comparison I want before hour twelve

I would diff the two JSON files on watched keys, and I would ignore cosmetic ordering because the dump is already sorted. A mismatch on preferred encoding or on stdout encoding is enough reason to block an encode patch. A mismatch on the executable path or the version string is enough to block any patch at all. Matching encodings would tempt me to skip the rest, and that temptation is the hole in this notebook.

python3 - <<'PY'
import json
from pathlib import Path
local = json.loads(Path("local-receipt.json").read_text(encoding="utf-8"))
remote = json.loads(Path("remote-receipt.json").read_text(encoding="utf-8"))
keys = (
    "version",
    "utf8_mode",
    "preferred_encoding",
    "stdout_encoding",
    "stdout_errors",
    "stdout_isatty",
)
for key in keys:
    print(f"{key}: local={local.get(key)!r} remote={remote.get(key)!r}")
PY

Would I treat a matching pair of receipts as proof that the original job is finally healthy? A matching receipt only says the text boundary looks alike, and the original exception can still be a logic bug. The point of the freeze is to stop a text fix from hiding a different failure underneath it. I would still read the exception type before I decide that encoding was the layer involved.

A probe I would run, and then revert

If the remote encoding is ASCII, or stdout errors are strict, the non-ASCII sample is a useful alarm. I would rerun the original command under an explicit mode, and I would keep that rerun labeled as a probe. I would use an explicit UTF-8 mode for that probe, and I would write the new receipt beside the old one. I would not edit application code in that same hour, even if the probe suddenly looks clean.

PYTHONIOENCODING=utf-8:strict python3 receipt.py remote-utf8-probe.json
python3 -X utf8 receipt.py remote-x-utf8.json

If the probe makes the exception vanish, I still would not land scattered encode calls through the codebase. I would record which boundary failed, stdout or a file open, and I would change that boundary on purpose. If the probe changes nothing, a suggestion to encode the string is probably aimed at the wrong layer. I would keep both receipts, because the better-looking run is not the run that originally failed.

A decision table I would not skip

What the receipts show	What a suggestion often says	What I would do in this window
Preferred encodings differ	Call encode with UTF-8 on the value	Reject it. Probe the process mode, then fix the boundary that actually writes.
Encodings match, versions differ	It works on the newer minor	Reject it. I am not scoring the interpreter that failed.
Encodings match, tty flag differs	Add a progress bar or color	Park it. A tty split is a different note, not an encoding patch.
Receipts match, probe still fails	Retry the same call unchanged	Stop asking for style edits. Capture the exception type and the failing call.
Remote file is missing	Recreate the script from memory	Stop. A retyped script is a new tree, so the hash no longer means anything.

The table is a gate, not a scoreboard, and I would not add a row just to make a weak patch look measured. If none of the rows match the receipts in front of me, the honest move is to stop and widen the fingerprint. Would I invent a fifth row in the moment so the hour does not feel wasted on a quiet box? I would write the mismatch in prose instead, and I would leave the table alone until the next window.

What I would expect to break

I am not publishing a count of failures, because this notebook is a procedure rather than a dataset I measured. These are the breaks I would watch for, and the response I would repeat if one of them shows up. None of them requires a named model, and none of them requires the free host to have a particular size. If your run shows a sixth break, write it down, and do not sand it off to match this list.

1. The remote stdout encoding is ASCII or empty, while the laptop receipt says UTF-8, so the marked sample dies only on the far side.
2. The file write uses an explicit UTF-8 open, so the file looks fine, and the crash is only the inherited stdout handler.
3. The remote shell has a C locale, while a later login looks healthy, which means I compared the wrong session entirely.
4. The model returns a confident wrapper, and the answer never mentions the encoding fields or the receipt hash I pasted.
5. The free host drops the session before I copy the remote receipt off, so I have a story and no artifact left.
6. The receipt command wrote to stdout on an ASCII host, so it died, and a UTF-8 file open is the repeat I would keep.

That fourth break is the one I would take as a stop sign, not as a prompt to ask again more nicely. If the explanation does not cite a field from the receipt, why would I let it edit the job? I would rather rerun the probe than accept a patch that could have been written for a different machine. A fluent answer can still be a wrong answer, and fluency is not one of the watched keys.

Questions I would ask before the second day

Before I open the second day, I would ask whether the remote receipt was copied off the host. I would ask whether the probe used the same script bytes as the laptop run did. I would ask whether the suggestion named a watched field, or only renamed the exception in prose. I would ask whether I am about to edit code just because the prompt felt inexpensive.

What I would repeat across the remaining hours

• From hour zero to hour two, I would write both receipts, copy them off the remote host, and refuse to open a model prompt.
• From hour two to hour eight, I would run the non-ASCII probe, then one explicit UTF-8 probe, keeping the earlier receipt intact.
• From hour eight to hour twenty-four, I would ask only with both receipts attached, and reject answers that ignore them.
• From hour twenty-four to hour forty-eight, I would repeat the original command once under the chosen boundary, and then I would stop.

I would repeat the reject rule more often than I would repeat the wording of the prompt. Another wording of the same patch is not new evidence, even when it sounds cleaner than the first. A new receipt after a deliberate mode change is new evidence, and it is the only kind I want on the second day. A third suggestion can feel cheap when model access is free, and that feeling is not a reason to continue.

What I would scrub before a prompt

I would remove the platform line if it contains a node name, and I would remove any path that sits under a home directory. The hash can stay, because it lets me detect a later edit without showing the machine that produced it. I would not add command arguments that might contain tokens, even when the failure looks like a simple text error. If I cannot scrub it quickly, I would skip the model step and keep the comparison local for the rest of the window.

Limits, and who should walk away

This approach will not choose the right text contract for your users, and it will not prove that UTF-8 is always correct. Some libraries encode bytes before they ever touch standard output, so a green probe can sit beside a red worker. Windows locale APIs belong in a different notebook, and I would not pretend this POSIX receipt covers that ground. A passing probe is a clue about the boundary, not a release decision for the whole service.

Do not point this script at a full environment dump, and do not paste secrets beside a receipt that was carefully redacted. Free model access and a free server are not a capacity plan, a hardware quote, or a retention guarantee. I was not given a quota or a machine shape, so I would copy artifacts out and keep another host in reserve. If the box is gone at hour forty-seven, the notebook still works only when the JSON files already sit on your laptop.

You should walk away if policy forbids sending even a redacted trace to an external model at all. You should also walk away if the failing stream is binary, because a text probe will lie to you there. You should walk away if you need an audited production image rather than a scratch box for a day. In those cases the receipt script can still run locally, and the model step should stay closed.

If that free server is already the spare box on your account, I would make the receipt the first command there. I would ask the free model nothing until the remote file is sitting on my laptop beside the local one. The article is still useful if you swap in any other second host, and I would rather you do that than skip the freeze. Take the reject rule, leave the vendor out, and the next forty-eight hours still have a usable shape.