session: count framed payload lengths in characters, not bytes

[ale-rinaldi]

A pre-existing bug, found while validating agent management against a live account.

The bug

Every command response is framed as <id>:<length>:<payload>, and that length counts characters — the service produces it the way JavaScript's String.length and Java's String.length() do. dwshell sliced the body by bytes, which agrees only while everything is ASCII. One non-ASCII character and the payload is cut short, leaving JSON that ends mid-structure.

Captured live, a rejected agent name:

K:K11:71:K:{"message":"L'agente 'x' già esiste.","status":"error"}

71 characters, 72 bytes. dwshell took 71 bytes, lost the closing brace, and reported:

dwshell: create agent "x": parse agent commit response: unexpected end of JSON input

instead of the service's own message.

Blast radius — narrower than it looks, and worth recording

The agent escapes non-ASCII in its own responses (à), so anything coming from an agent was never affected — file listings with accented names included. I verified this: dwshell ls over a directory containing città-più-perché.txt works correctly even without this fix, because the agent sends the name escaped and the payload stays pure ASCII.

It is the account channel that truncates, where the service answers with literal UTF-8. Localized error messages are the common case, which is why this only surfaced on an Italian account.

The fix

Payload lengths are consumed in UTF-16 code units rather than Go runes: up to U+FFFF the two agree, and beyond it the service counts two, so counting runes would have traded one off-by-one for another. There is a test for each.

Verification

	Before	After
Rejected agent name (live)	unexpected end of JSON input	L'agente 'x' già esiste.
ls over accented filenames (live)	works (agent escapes)	works
Unit tests: character length, UTF-16 beyond the BMP	—	pass

gofmt, go vet, go test -race ./... green.

🤖 Generated with Claude Code

https://claude.ai/code/session_01MvidAFW9a2r4hTgHPW9ywG