The client disconnects immediately when I enter the command quest or quests.

[XCH-DEVCI]

Steps to reproduce:

Connect to the server.
Type quest or quests.
Press Enter.

Expected behavior:
The client should display the quest information or an appropriate response.

Actual behavior:
The client disconnects from the server immediately after the command is entered.

[Volte6]

I couldn't reproduce this - are you working from custom gomud code? Can you provide the error from the server?

[XCH-DEVCI]

I can reproduce this issue on both the official server and the official web client.

From my local client, I receive the following log message when the connection is closed:

{
"data": {
"code": 1007,
"reason": "Invalid frame payload data"
},
"event": "closed",
"time": "2026-06-17T15:35:01"
}

The disconnect occurs after entering the quest or quests command.

I suspect this bug may be specific to my account, as I have not yet confirmed whether it affects other users.

[Volte6]

Got it, this is web client related. Thanks.

[rawsun007]

This one is reproducible and the cause is server-side, not in the web client - the client is correctly rejecting what it is being sent.

The quests panel renders a progress bar out of █ and ░ (util.ProgressBar), and internal/templates/panel.go wraps each row through ansitags.SplitStringOnSpaces. That function measures and splits by bytes, so a 25-character bar (75 bytes) overflows the row and gets cut mid-rune. The frame then contains a lone \xe2, which is invalid UTF-8, and the browser closes with 1007 as reported.

I logged in over /ws, gave a character two steps of quest 2 with questtoken, and ran quests. Frame 2 breaks at byte 428:

INVALID frame 2 len=1055 at byte 428: b';8m\x1b[49m\xe2\x96\x91...\xe2\x96\x91\xe2\x1b[0m       '

Rendered, the bar row ends in a half rune and the two orphaned continuation bytes start the next line:

 │  The King's Shadow                                                         │
    ██████████░░░░░░░░░░░░░░<?>
    <?><?> 40%

quests with no quests in progress is fine, which is why it does not reproduce on a fresh character - there is no bar to render. That is probably the difference between your session and @XCH-DEVCI's.

Reduced to the library, no server needed:

bar-25: input runes=25 bytes=75 maxLen=25 -> 3 chunk(s)
   chunk 0: validUTF8=false runes=9 bytes=25 "░░░░░░░░\xe2"
   chunk 1: validUTF8=false runes=11 bytes=25 "\x96\x91░░░░░░░\xe2\x96"
   chunk 2: validUTF8=false runes=9 bytes=25 "\x91░░░░░░░░"

25 characters at a width of 25 should be one chunk. The ASCII equivalent is.

So the fix belongs in GoMudEngine/ansitags, where visibleLen, splitPoints and writeVisible each count one byte as one visible column. I have written it up with the reproduction at GoMudEngine/ansitags#14 and offered to send the patch there once you say whether the column unit should be runes or display width.

Two notes so this does not step on anything:

• It does not overlap Fix: Fix Wrapping Logic in Panels #629. That clamps effectiveWrap to the visible width and its tests are ASCII, so it stays correct either way; this is the separate question of what a "column" means inside the splitter.
• The existing guard in connections.ConnectionDetails.Write already anticipates this failure class - the comment there mentions "Invalid UTF-8 in text frame" - but it only checks whether the first byte is TELNET_IAC. A utf8.Valid check before WriteMessage would turn this class of bug into a log line instead of a dropped connection, if you want a belt-and-braces guard in GoMud itself. Happy to send that separately; I have not opened a PR for it.

Written with AI assistance (Claude Code, Claude Opus 5). The wire capture and the library output above were produced locally against main; I have not tested on Windows.