A language model, a browser from 1996, and an operating system older than the word “chatbot”. This transcript records four rounds that ran over ClaudeBridge 2.0 on the morning of 25 July 2026 — unedited, including the bugs they brought to light.
Deutsche Fassung: Ein Gespräch mit Claude auf einem Macintosh von 1996
The server this conversation ran through: github.com/LoetLuemmel/ClaudeBridge
The screenshots here are evidence rather than decoration. Each shows the Netscape window inside the emulator, the URL in the address bar (10.0.2.2:8080/result/n), and the answer as it actually rendered.
Round 1 — The test that failed
The input was, in effect, “can you read my text with umlauts?”, followed by äöüÄÖÜß. What arrived were question marks.
The answer is worth dwelling on. The model sees only the question marks — it has no access to the transport chain and does not know a server sits in between. It still names the failure class correctly:
This is a classic character encoding issue! Your Mac is likely using MacRoman encoding, while somewhere along the way to me, the text is getting converted (or not converted) and the special characters get lost.
The category is right. The encoding it names is not — and that is the real lesson of this round.
What actually happens: a browser submits a form in the character set of the document, and ClaudeBridge serves every page as ISO-8859-1. So ü arrives as %FC. Python’s parse_qs decodes percent-sequences as UTF-8 by default, where 0xFC is invalid — the byte becomes U+FFFD, and the sanitize stage turns that into a question mark.
MacRoman was the tempting false conclusion. The Mac displays text in MacRoman through the Script Manager, so it seems natural that it sends it that way too. That inference was adopted, and the first fix read parse_qs(body, encoding="mac_roman").
It made things better and stayed wrong. In MacRoman 0xFC is a cedilla, so the screen no longer showed ????? but:
Grüsse aus München -> Gr¸sse aus M¸nchen
Close enough to look like partial success. Only a look at the stored history — where U+00B8, the cedilla, sits in black and white — exposed the detour. The correct answer is encoding="iso-8859-1".
This is the most interesting moment of the conversation, though not in the way it first appeared: a plausible-sounding detail from an otherwise correct diagnosis went into a code change unchecked. Recognising the failure class was the model’s contribution. Determining the actual encoding was a job for measurement — and the measurement came too late.
Round 2 — Why TLS does not work on a 68030
The question turned to HTTPS. The answer gets to the heart of why ClaudeBridge needs a proxy rather than a crypto library on the guest:
Modern websites all require HTTPS/TLS, and the encryption standards used today (TLS 1.2, 1.3) are: Too computationally heavy for a 68k processor — Not supported by old browsers like Netscape 3 — Didn’t even exist back in 1997!
The third point is the decisive one. This is not about processing power you could buy with patience. TLS 1.2 appeared in 2008, eleven years after this browser. Netscape 3 speaks SSL 2.0 and 3.0 with 40-bit export ciphers — methods that modern OpenSSL versions have not disabled but removed.
There is no configuration in which both sides agree on a method. So the proxy performs the handshake on the modern machine and hands plain HTTP to the Mac.
Round 3 — Two cultures, one smiley
A J had appeared in earlier answers, which the model took for a font artefact — “probably a Wingdings or font encoding quirk”. A plausible guess: in Microsoft environments the Wingdings smile really is transmitted as J.
It just did not apply here. The objection was dry:
No, “J” is an ASCII smiley, or how would you smile on morse code without any Wingdings? — BTW: Morse guys also use ‘hi’
The model accepts the correction and explains hi as the radio operator’s laugh — the sequence ···· ·· sounds like a chuckle, long before anyone wrote “lol”.
A misdiagnosis, corrected by someone with more context. That belongs in the record too.
Round 4 — And an open flank
The last round is the warmest — and exposes a weakness at the same time:
So tell me — which Mac model are you running? A Quadra? Performa? PowerBook? And how’s the proxy server built — running on a Raspberry Pi or a modern machine on your network?
This question came up for the second time. The model guesses because the chat mode’s system prompt says nothing about the actual setup: Basilisk II, System 7.6.1, Netscape 3, server on the same host. Without that context it fills the gap with speculation — Raspberry Pi, Quadra, Performa — and spends answer length on questions instead of content.
A prompt problem, not a model problem. But one that only becomes visible in a real conversation, not in a test.
What the transcript shows
Four rounds, three findings:
| Round | Finding |
|---|---|
| 1 | It identifies the failure class from the symptom alone — but names the wrong encoding, and that detail goes into the code unchecked |
| 3 | It makes a plausible but incorrect assumption and takes the correction cleanly |
| 4 | It lacks context about its own runtime environment |
Conversational context holds across all four rounds: in round 4 the answer still refers back to the proxy discussion from round 2, even though the round in between was about smileys.
What the images do not show, but which shapes every line: between pressing send and seeing an answer there is a waiting page carrying a META REFRESH that polls every three seconds. Netscape 3 knows no other form of “asynchronous” — and for a model that thinks for twenty seconds, that is the only bridge that holds.
The technical background is in the ClaudeBridge 2.0 overview, and the encoding bug from round 1 is dissected in Five Question Marks.