Large integer precision error in Bash command output rendering

[neewamp]

Claude Code incorrectly displays large integers in bash command output, showing a different value than what was actually output by the command.

Steps to Reproduce

1. Run the following command in Claude Code:

echo '348555896224571969'

Or with jq:

echo '{"value": 348555896224571969}' | jq -c .value

Expected Behavior

Claude Code should display: 348555896224571969

Actual Behavior

Claude Code displays: 348555896224571970 (off by 1)

Verification

Running the same command in a native terminal correctly outputs: 348555896224571969

Environment

• Claude Code version: v2.0.37
• Model: Sonnet 4.5 (Claude Max)
• Platform: macOS (Darwin 24.3.0)

Screenshots

[rrwright]

[mmrunosquare]

I can confirm this issue also occurs on Windows.

Environment:

• Claude Code version: 2.0.37
• Platform: Windows 11
• Model: Sonnet 4.5

This suggests the issue is platform-independent and likely related to how Claude Code processes numeric values in bash output.

[chainhead]

Variant

 echo '0.348555896224571969'

● Bash(echo '0.348555896224571969')
  ⎿  0.34855589622457195

● The command executed successfully and output: 0.348555896224571969

[sammcj]

I asked Claude Code to inspect ~/.local/bin/claude to see if it could figure this out:

⏺ Based on my investigation, I've identified the issue. Here's what's happening:

  Root Cause: JavaScript Number Precision Limits

  The Claude Code CLI binary (at ~/.local/bin/claude) appears to be built with Bun (a JavaScript runtime). When it receives output from bash commands, it's parsing the JSON/text through
  JavaScript, which has a fundamental limitation:

  - JavaScript's Number type uses 64-bit IEEE 754 floating-point
  - It can only safely represent integers up to 2^53 - 1 = 9,007,199,254,740,991
  - Your number 348,555,896,224,571,969 exceeds this limit by a huge margin
  - When JavaScript parses this number, it loses precision and rounds to the nearest representable value (348,555,896,224,571,970)

  The Problem Flow:
  1. Bash correctly outputs: 348555896224571969
  2. Claude Code's JavaScript/TypeScript code parses this (likely as JSON or when processing the output)
  3. JavaScript converts it to a Number, losing precision → 348555896224571970
  4. This incorrect value is displayed to you
  5. But I see the original correct value in my tool result

  Why I See the Correct Value:
  The tool result that comes to me likely preserves the original string representation before it gets re-parsed by the UI layer you're viewing.

  Solution:
  Claude Code needs to handle large integers differently:
  1. Keep large numbers as strings throughout the processing pipeline
  2. Use BigInt for integer values that might exceed Number.MAX_SAFE_INTEGER
  3. Parse JSON with options to preserve large numbers (e.g., using a custom JSON parser that handles big integers)

  This is a bug in the Claude Code CLI that should be reported to Anthropic.

I'd raise a PR to fix this but it's closed source.

[amorriscode]

Thanks for the report! A fix will go out in the ~next release or so. 🫡

Also, for clarification, this bug was only impacting the display of numbers in the TUI, not what the model sees. The model sees raw results from bash.

[rrwright]

@amorriscode This bug report was about the symptom that affects the display of numbers in the TUI, but the real bug/design flaw is using jq or JSON as a transport mechanism between components, agents, or tools. JSON's number range is famously poor and is even architecture-dependent. So if you use jq or JSON to connect components or tools, you will have this same problem silently occurring elsewhere without visibility in the UI.

This is a bigger deal than it seems like! A confidence-inducing fix would include a blog post describing a top-to-bottom audit of jq/JSON used as a transport layer between tools and components. Not just a patch to the UI as the most visible problem.

[github-actions]

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.