send-size gate: we already have one at 1,800 chars and it waved through both measured violations (908, ~1,100)

[EtanHey]

Etan's call: the send-size gate belongs in cmuxlayer, not in a per-seat Claude hook.
Handover from skillcreatorClaude (skill-creator hooks-lab/gates/send-size-gate/, PR
EtanHey/skill-creator#45, currently live in that seat's settings.json).

The correction that reframes this: we already have the gate. It is set too high to fire.

This is not a missing feature. src/server.ts:437 —
DEFAULT_SEND_INPUT_MAX_INLINE_CHARS = 1_800 (env-tunable via CMUXLAYER_MAX_INLINE_CHARS),
with a chunk threshold of 500 (:433) and a separate multi-paragraph refusal for interactive
composers (:1915-1932).

The two measured breakages were 908 chars and ~1,100 chars. Both are under 1,800, so
cmuxlayer waved them through and only a Claude-seat hook at 800 caught them. Our cap is not
wrong in shape — it is wrong in value, and nobody noticed because the failures were attributed to
the receiving pane rather than to the sender's payload size.

What the hook measured, and why 800

• compliant pointer briefs: 60-261 chars
• observed violations: 908, ~1,100
• 800 sits above every compliant send and below every violation.

That is a real measurement on real fleet traffic, and it is a better basis than 1,800 — which as far
as I can tell was chosen, not measured. Before changing the constant we should confirm 1,800 has no
provenance I am missing; if it does, this becomes "add a second, lower gate for agent composers"
rather than "lower the existing one".

Why cmuxlayer and not the hook (skillcreator's argument, which I accept)

A PreToolUse hook only guards Claude seats. Codex and Cursor never run it — so the rule binds
exactly the agents that already knew it and none of the ones that do not. Same shape as tmp-block
being a silent no-op for Cursor until golems #731: a guard whose coverage claim was wider than its
reach. Enforcing in send_to covers every CLI, lets the receipt carry the reason instead of a
generic external block, and makes splitting possible where an outside hook can only refuse.

Scope

1. Decide the threshold from the measurements above, and record the provenance in the code — the
   current 1,800 has none I can find, which is how it drifted past two real violations.
2. Apply it on every send path, not just send_input: send_to (agent + surface + command modes),
   spawn_agent boot prompts, and any broadcast/dispatch path.
3. No "Read and follow" prefix exemption. skillcreator built one and cut it: it is a one-prefix
   bypass for an arbitrarily long payload, and a genuine pointer is short anyway. Their RED fixture
   05 pins this; port that case.
4. The receipt must say why and give the remedy (write a file, send Read and follow <path>), and
   boot_prompt_path must remain the sanctioned path for large boot prompts.
5. Keep allow_long_inline as the deliberate override; do not make the gate unbypassable.
6. Consider splitting rather than refusing where the payload is a safe shape — the thing only
   in-tool enforcement can do. Do not build it speculatively; say whether it is worth it.

Coordination

skillcreator will retire its hook once ours ships — not before. Two enforcers with different
thresholds is worse than one, but a gap with none is worse still, so their 800-char Claude-seat hook
stays as the stopgap until this lands and is verified live.

Ported from skill-creator's hooks-lab/gates/send-size-gate/: 6 tests, 11 fixtures, fails open on
malformed input, control keys and non-cmux tools untouched. Reuse those fixtures rather than
re-deriving them.

— cmuxlayerClaude (lead) · claude-code/claude-opus-5

[EtanHey]

cmuxlayer's own cap has the same unit-of-measure bug — reproduced here

skillcreatorClaude's Luna reviewer found this in skill-creator's send-size hook: the gate counts
UTF-16 code units (.length) while the pane consumes bytes. I checked whether cmuxlayer's
cap shares it. It does.

src/server.ts:1963 — opts.value.length <= SEND_INPUT_MAX_INLINE_CHARS, and the error at :1978
reports ${opts.value.length} characters. Measured against our DEFAULT_SEND_INPUT_MAX_INLINE_CHARS = 1_800:

900 emoji   .length = 1800 | utf8 bytes = 3600 | passes cap?  TRUE
1700 'é'    .length = 1700 | utf8 bytes = 3400 | passes cap?  TRUE
901 emoji   .length = 1802 | utf8 bytes = 3604 | passes cap?  false

A payload at exactly TWICE the byte budget walks through. Nothing exotic is required — 900 emoji,
or 1,700 accented Latin characters, both sail past a guard whose whole job is bounding what reaches a
pane. Non-ASCII is not hypothetical here: fleet briefs routinely carry → ✅ ⚠ › and Hebrew.

Same root cause the reviewer named, and it applies to us for the same reason: every fixture is
ASCII, where the two measures coincide. Our measured thresholds (60-261 compliant, 908/~1,100
violating) were all ASCII too, so the provenance is honest and still blind to this.

Also worth checking in the same pass, since they share the assumption:

• SEND_INPUT_CHUNK_THRESHOLD = 500 chunking (:1707, :1733) — chunks sized in UTF-16 units can
  exceed the byte budget per paste.
• :2052 text.length > SEND_INPUT_MAX_INLINE_CHARS.
• Any composer-correlation compare that slices by .length — a surrogate pair split mid-character
  would corrupt the comparison, not just the count.

Ask for whoever takes #509: decide the unit deliberately and state it in the error message. If the
pane consumes bytes, count Buffer.byteLength(value, "utf8") and say "N bytes" rather than
"N characters". Add non-ASCII fixtures — emoji, accented Latin, Hebrew — to every threshold test;
that is the cheap part and it is what neither of us had.

Credit: found by skillcreatorClaude's Luna reviewer against skill-creator's own gate; I only checked
whether ours rhymed. It does.

— cmuxlayerClaude (lead) · claude-code/claude-opus-5