dor send prompt arrives truncated in Claude Code (missing 1,022-byte prefix) #679

Activity

1. dormouse-bot commented on Sep 17, 2026

   

   dormouse-bot

   on Sep 17, 2026

   Collaborator

   More actions

   No fix yet — I could not reproduce this in CI, and the reason is itself the useful finding: nothing between dor send and the PTY can produce this failure shape, so the discard almost certainly happens in the kernel tty layer, and dor send is not the only caller exposed to it.

   The chain above the PTY is length-blind. dor send concatenates --text and the --key byte and hands over one string (encodeSendInputs). The control socket, the Rust bridge, and the sidecar all frame with newline-delimited JSON and reassemble from a buffer, so a framing fault would corrupt the JSON and fail the call, not yield well-formed ASCII. The host handler type-checks params.input and passes it through unsliced (use-dor-control.ts#L841). The cut also lands mid-word inside with at a pure byte offset, which no JSON, UTF-8, or frame boundary in that chain can land on. I confirmed your arithmetic against the transcribed prompt: 1600 bytes, surviving text at offset 1022, 578 bytes delivered.

   What that leaves is the last hop, which has no flow control at all. write() in pty-core.js is p.write(data) — one unbounded burst into the pty master, no chunking and no pacing, and both hosts share it. A prefix vanishing while the suffix survives intact is the signature of an input-queue flush, not of per-byte drops (those would leave a hole in the middle, since the app is draining concurrently). 1022 sits just under BSD's 1024-byte tty input-queue bound, which is consistent with the flush happening once the queue crossed it.

   The wider consequence, and why this probably isn't a dor send bug. That same unguarded write() is the only path for clipboard paste too — writePasteToPty writes the whole payload, bracketing markers included, in one call. Bracketed paste doesn't help here: the app is still reading the same tty in raw mode, so the same queue bound applies. If the mechanism is what the shape suggests, pasting more than ~1KB into any raw-mode TUI on macOS loses its head just as silently, and the durable fix is chunk-and-pace inside that one shared write() rather than anything in dor. The sent response is unconditional by construction — the handler responds right after writePty and there is no acknowledgement channel from the PTY — so no amount of care in dor can make the success report honest; bounding the burst is what would.

   One run settles it. This isolates the kernel from everything Dormouse does — no node-pty, no sidecar, no webview. On this Linux runner it shows no loss at any size (the master write goes short at 16KB and libuv retries it, which is the correct behavior); if starts_at comes back non-zero on your Mac, the tty layer is confirmed and the fix location is settled.

   tty-input-limit.py — run on the affected Mac

   #!/usr/bin/env python3
   """Isolate whether the kernel tty layer discards a large one-shot write to a
   pty master. No node-pty, no Dormouse: just openpty + raw slave + one write."""
   import os, pty, select, termios, tty
   
   def probe(n, reader_delay=0.05):
       master, slave = pty.openpty()
       tty.setraw(slave, termios.TCSANOW)          # what an Ink/TUI app does
       payload = bytes(48 + (i % 10) for i in range(n))
       written = os.write(master, payload)          # one burst, like pty.write()
       got = b""
       while True:
           r, _, _ = select.select([slave], [], [], reader_delay)
           if not r:
               break
           got += os.read(slave, 65536)
       os.close(master); os.close(slave)
       start = payload.find(got[:32]) if got else -1
       return written, len(got), start
   
   print(f"{'bytes':>7} {'accepted':>9} {'received':>9} {'starts_at':>10}")
   for n in (512, 1024, 1200, 1600, 2048, 4096):
       w, r, start = probe(n)
       print(f"{n:>7} {w:>9} {r:>9} {start:>10}")

   Linux runner, for comparison — starts_at is 0 at every size, meaning nothing was dropped:

     bytes  accepted  received  starts_at
       512       512       512          0
      1024      1024      1024          0
      1200      1200      1200          0
      1600      1600      1600          0
      2048      2048      2048          0
      4096      4096      4096          0
   

   reader_delay stands in for an app that isn't draining instantly. Raising it widens the window; a reader that drains fast enough may mask the loss, which also explains why the 367-byte retry succeeded without isolating length from timing.

   I stopped short of a fix deliberately: choosing a chunk size and pacing without a measured threshold is guesswork, and a wrong bound would look like it worked while still losing data on a slower reader.
2. nedtwigg

   closed this as completedin #689on Sep 17, 2026