Claude Code is simultaneously the most useful and lowest quality app I use. It's filled with little errors and annoyances but succeeds despite them. Not to mention the official documentation is entirely vibe-copywritten and any quality control is cursory at best.
It forcibly installs itself to ~/.local/bin. Do you already have a file at that location? Not anymore. When typing into the prompt, EACH KEYSTROKE results in the ENTIRE conversation scrollback being cleared and replayed, meaning 1 byte of new data results in kilobytes of data transferred when using Claude over SSH. The tab completion for @-mentioning is so bad it's worthless, and also async, so not even deterministic. You cannot disable their request for feedback. Apparently it lies in tool output.
It truly is a testament to the dangers of vibe coding, proudly displayed for everyone to take an example from.
I use it daily for boilerplate and CRUD stuff, and have been since it came out. I honestly haven't experienced any bugs at all with it other than Anthropic server outages, etc. As far as agentic coding tools go, nothing else is close.
That being said, it's still an LLM, and LLMs are more of a liability than an asset to me. I was an early adopter and still use them heavily, but I don't attempt to use them to do important work.
The "failed to read file"/"failed to write file" errors that are constantly being displayed is the most glaring imo. I even get it in the interactive web version of claude.
JavaScript (in)famously stores all numbers as floating point resulting in silent errors also with user perceived integers, so this might be an indication that Claude Code number handling uses JS native numbers for this.
It seems like it, but it can't be only that. A float64 representation of an int in the range 2^58 to 2^59 should be rounded to multiples of 2^6, i.e. 348555896224571968 as you found (3.48555896224571968E17)
(the final digit 9 in the math.log2() expression was lost, it's 2^58 not 2^54)
The unexpected output (according to the bugreport) arises from javascript, it does NOT round like everything else for reasons I don't understand. It seems to prefer rounding to arbitrary multiples of 10 in my limited testing.
This symptom was affecting display of numbers in the TUI, but the real bug/design flaw is using jq or JSON as a transport mechanism between components or between tools. JSON's number range is famously poor and it 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 most visible problem.
If there is a conversion to IEEE 64 bit double involved, that type is only guaranteed to record 15 decimal digits of precision, so this number cannot be represented with enough precision to recover all of its original digits.
In C implementations, this value is represented as DBL_DIG, which is typically 15 on systems with IEEE floating point.
(There is also DBL_DECIMAL_DIG which is typically 17; that's the opposite direction: how many decimal digits we need to print a double such that the exact same double can be recovered by parsing the value. DBL_DIG existed in C90, but DBL_DECIMAL_DIG didn't appear until, it looks like, C11.)
First, HN prefers the source title unless that title is misleaing clickbait.
Second, the problem is not consistently off-by-one errors, as there is a manifestation shown in the bug of an off-by-much-less-than-one error. The problem looks like a "for some reason it seems to be roundtripping numbers in text through a numeric representation which has about [perhaps exactly] the same precisions issues as float64" issue.
I don't think this is a bug specifically with Claude Code, rather it's due to Claude Code having javascript in the backend. The interesting thing to me is that the numeric string was interpreted as an integer.
I forgot which blogpost mentioned it, but to paraphrase it states that managers won’t understand why you can’t just fix a bug like this in a few minutes like you would in traditional software.
This might be one of those cases, where the problem arises from the training set somehow.
This seems to be a software bug and not something about model behavior, though the model is in some sense doing the wrong thing by internally evaluating what the echo command should output rather than saying what the output actually is.
Edit: Based on the above comment showing javascript numerics behavior changing, it's more like some unusual interaction with the numeric string in the bash command being interpreted as an integer and running into precision issues.
Looks like it has to be the full tool output to be coerced:
> Can you run this through bash: echo '348555896224571969 plus 2 is 348555896224571971'
Bash(echo '348555896224571969 plus 2 is 348555896224571971')
⎿ 348555896224571969 plus 2 is 348555896224571971
CGamesPlay|3 months ago
It forcibly installs itself to ~/.local/bin. Do you already have a file at that location? Not anymore. When typing into the prompt, EACH KEYSTROKE results in the ENTIRE conversation scrollback being cleared and replayed, meaning 1 byte of new data results in kilobytes of data transferred when using Claude over SSH. The tab completion for @-mentioning is so bad it's worthless, and also async, so not even deterministic. You cannot disable their request for feedback. Apparently it lies in tool output.
It truly is a testament to the dangers of vibe coding, proudly displayed for everyone to take an example from.
jimbo808|3 months ago
That being said, it's still an LLM, and LLMs are more of a liability than an asset to me. I was an early adopter and still use them heavily, but I don't attempt to use them to do important work.
DecoPerson|3 months ago
I just open a Claude Code Thread, tell it what I want, bypass permissions (my remote is a container), and let it work. And it works wonderfully!
I guess the “integrated” part of IDE is pretty important.
boxed|3 months ago
willm|3 months ago
https://www.youtube.com/watch?v=OGGVdPZTc8E&t=2s
ec109685|3 months ago
o11c|3 months ago
fulafel|3 months ago
mrspuratic|3 months ago
ec109685|3 months ago
amorriscode|3 months ago
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|3 months ago
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 most visible problem.
timenotwasted|3 months ago
> run cmd echo '348555896224571969'
I'll run that echo command for you.
Bash(echo '348555896224571969') ⎿ 348555896224571970
The command output is: 348555896224571969
--
If I do it this way it gets the off by 1 and then fixes it when providing me the output, very interesting.
kazinator|3 months ago
If there is a conversion to IEEE 64 bit double involved, that type is only guaranteed to record 15 decimal digits of precision, so this number cannot be represented with enough precision to recover all of its original digits.
In C implementations, this value is represented as DBL_DIG, which is typically 15 on systems with IEEE floating point.
(There is also DBL_DECIMAL_DIG which is typically 17; that's the opposite direction: how many decimal digits we need to print a double such that the exact same double can be recovered by parsing the value. DBL_DIG existed in C90, but DBL_DECIMAL_DIG didn't appear until, it looks like, C11.)
dvh|3 months ago
ahazred8ta|3 months ago
rrwright|3 months ago
Original: https://pasteboard.co/xTjaRmnkhRRo.png
Unilaterally Edited: https://pasteboard.co/rDPINchmufIF.png
sevg|3 months ago
> Otherwise please use the original title, unless it is misleading or linkbait; don't editorialize.
dragonwriter|3 months ago
First, HN prefers the source title unless that title is misleaing clickbait.
Second, the problem is not consistently off-by-one errors, as there is a manifestation shown in the bug of an off-by-much-less-than-one error. The problem looks like a "for some reason it seems to be roundtripping numbers in text through a numeric representation which has about [perhaps exactly] the same precisions issues as float64" issue.
cyral|3 months ago
alyxya|3 months ago
Insanity|3 months ago
This might be one of those cases, where the problem arises from the training set somehow.
alyxya|3 months ago
Edit: Based on the above comment showing javascript numerics behavior changing, it's more like some unusual interaction with the numeric string in the bash command being interpreted as an integer and running into precision issues.
amorriscode|3 months ago
ethmarks|3 months ago
rrwright|3 months ago
CGamesPlay|3 months ago