Title: 400 Invalid 'input[280].name' — tool name fails ^[a-zA-Z0-9_-]+$, intermittent and untraceable to config

Start by tracing how the request payload is assembled and how mod, MCP server, and skill tools are registered; the issue names no source files or tests. Reproduce a long session past 280 entries and identify whether validation can report the offending name and its source before sending, with the failure no longer presented as a generic connection error.

GUI version

0.1.37

Operating system

Windows

Reproduction steps

Not deterministic; I can only give the conditions it occurred under.

1 Windows · PowerShell 7 · Command Code CLI.
2 Long session with heavy tool use — ~40 file writes/edits under ~/.agents/skills/blender-skill/**, ~25 PowerShell commands, several activate_skill calls.
3 Keep going until the request payload array grows past ~280 entries.
4 At some later request, the call is rejected with the 400 below. Observed 4 times out of many requests in one session — always at input[280], never another index.
5 Type continue → the retry succeeds immediately, with the prompt and all user-controllable input unchanged.
I could not isolate a single triggering action. The reproducible facts are: long/heavy session, and the offending entry is always at index 280.

Expected behavior

Every name sent in the request payload matches ^[a-zA-Z0-9_-]+$.
An invalid name is rejected at registration time (mod, MCP tool, or skill), naming the offending value and its source so it can be fixed locally — not surfaced later as an opaque 400.
If the payload is validated client-side before send, the error should echo the offending input[N].name value.

Actual behavior

The request is rejected:
400 Invalid 'input[280].name': string does not match pattern.
Expected a string that matches the pattern '^[a-zA-Z0-9_-]+$'.
The error does not reveal the offending value, nor which mod / MCP server / tool registered it.
The session then shows Error: Connection error. Type "continue" to try again. — i.e. it presents as a network problem, which misdirects debugging.
continue retries and succeeds unchanged, so work is not lost but is interrupted.
The index is always 280 across 4 failures and the message is byte-identical, which suggests one stable bad entry that only becomes reachable once the payload array is long enough — and likely explains the intermittency.

Screenshots, recordings, or sanitized logs

Session: 00c51d00-8b59-423c-b038-865b3d9402bf
Traces: 2696bd3793740af5c8ebd500b8d6c10e, 7ae851ce9c6e747028e10ee3446685ef, 9b09f6a665e4efd1fbde25c8bd593c8d, e7a4e417443f60a36913f9c671ba765f, c868d6ca12480760eb2adbb3a710e17d

Safety check

• I removed credentials and private project information from this report.