Bug: Incorrect Offsets

[samot-gc]

I've been noticing a bug in the use of the Read tool.

It seems to get confused between initial line number and offsets. Sometimes it goes completely crazy.

It sometimes fixes itself, but not so often.

I haven't come up with a specific scenario to reliably replicate this - but it happens often. I haven't dug into the code to see why this might be happen (yet) either. I may do that in the future, but just recording here for now.

As a small workaround, I often just tell it to use cat file | head -22 | tail -10, for example, to read 10 lines starting from line 12. But, it like the Read tool - naturally, since it's an essential, in-built tool - so doesn't always follow this.

This is using GPT-5.5 (with/without 'fast' mode)

[raine]

Interesting, haven't seen that. It might be that terminal claude code hides lines so it's not obvious

[raine]

I will run the proxy with full traffic logging for a while (just deleted all logs, they accumulate to tens of gigabytes easily) and see if the logs get that

[raine]

• Best theory: GPT is occasionally treating Read.offset as a fuzzy line locator, and the
  current schema makes that easy.

  Evidence points that way:

  - The proxy forwards the Read schema into Responses function parameters at src/providers/
    codex/translate/request.rs:366. The Read-specific sanitizer only removes empty pages
    fields at src/providers/codex/translate/live_stream.rs:729.

  - The Read schema says both “line offset” and “line number to start reading from”. It
    also says output is cat -n style starting at 1, while actual tool results in the logs
    start at 0.

  - Two bad offsets look like decimal-place slips:
      - 1600 against a 170-line HTML file, likely meant around line 160.
      - 7990 after a prior read around 500..799, likely meant 799 or 800.

  - The 12001 case is weaker, but it appears in a number-heavy context with grep line
    numbers and prior tool IDs. Same shape: model emits a valid JSON integer that has no
    file-line meaning.

  So my current ranking is:

  1. Tool semantics ambiguity: zero-based output, schema wording, and “line number” versus
     “offset” are pushing the model into bad arithmetic.

  2. Number leakage from context: grep line numbers, SVG coordinates, long heredocs, and
     tool IDs are all nearby.

  3. Schema accepts impossible values: offset allows huge integers, so the model’s invalid
     file-specific value passes schema validation.

  4. Proxy translation bug: low probability from the traffic. The captured SSE contains the
     bad argument before Claude Code runs Read.

  The practical first fix I’d try is tightening the outgoing Read description for Codex:
  “offset is a zero-based line index from the displayed Read output; omit it unless
  continuing a prior Read; use previous offset plus returned line count; never use
  character offsets.” A diagnostic guard for clearly impossible offsets would also make
  future captures cleaner.

[raine]

Trying something in the latest version

[samot-gc]

I can try your fix locally using cargo run -- serve. That won't affect claude-code-proxy (I think I was on v0.1.2), so I'll switch that off. Is that right?

For what it's worth, I've not been getting the error as much recently - and not using an updated version. GPT-5.5 still likes to read big chunks - much bigger than I recall Claude doing - but hasn't been erroring this chat.

[raine]

I've been testing various fixes lately but it doesn't seem to go away completely.

If you don't want to install the latest you can do that cargo run yes.