Repository navigation
Gemini CLI crashed after inactivity with a RangeError: Invalid string length. #19664
Description
What happened?
RangeError: Invalid string length
at Ink.onRender
More details in b/485951886
Note that this is after multiple days of inactivity in a tmux session
What did you expect to happen?
No error
Client information
Client Information
Run gemini to enter the interactive CLI, then run the /about command.
> /about
# paste output hereLogin information
No response
Anything else we need to know?
No response
Activity
Nixxx19 commentedon Feb 20, 2026
Hi @chrstnb! Thanks for reporting this.
Fixed the RangeError issue. The problem was unbounded shell output accumulation - background shells were appending output without any limit, causing the string to grow indefinitely until it exceeded JavaScript's maximum string length (~1GB).
Solution:
MAX_SHELL_OUTPUT_SIZElimit (10MB) for accumulated shell outputResult:
The CLI no longer crashes after long periods of inactivity. Shell output is automatically truncated at 10MB, keeping the most recent output while preventing unbounded growth.
Opened PR #19716 with the fix. Please review when you have a chance!
ProthamD commentedon Mar 6, 2026
/assign
gemini-cli commentedon Mar 6, 2026
👋 @ProthamD, you've been assigned to this issue! Thank you for taking the time to contribute. Make sure to check out our contributing guidelines.
Nixxx19 commentedon Mar 7, 2026
hey @ProthamD, i've already opened PR #19716 which addresses this issue. feel free to take a look and let me know if you have any feedback. this should help avoid duplicate work.
ProthamD commentedon Mar 7, 2026
Hey @Nixxx19 , thanks for flagging that — I did check out #19716 before opening this PR! I went ahead with a separate implementation because it includes a couple of improvements:
Pre-concatenation safety check — the original approach checks the length after [shell.output + chunk, which means the + operator itself can throw RangeError if both strings are large enough. This PR checks the combined length before concatenating and pre-truncates to make the join safe.
Amortized truncation — instead of slicing on every single chunk append once the cap is hit, truncation only fires when output exceeds [MAX_SHELL_OUTPUT_SIZE + SHELL_OUTPUT_TRUNCATION_BUFFER](11 MB), reducing the O(n) copy cost significantly in high-throughput shells.
Two tests covering both the below-threshold (no truncation) and above-threshold (triggered truncation) cases.
Happy to collaborate — if the maintainers prefer to go with #19716, I'm totally fine closing this one. Just wanted to make sure that the code doesnt break and run efficiently!
also I didnt see anybody was assigned to it just saw you raised an PR, as per code of conduct I thought anybody who wants to raise an PR has to assign the problems to themselves first, so I assigned that to me.
Nixxx19 commentedon Mar 7, 2026
Hi @ProthamD, thanks for taking a look at this issue and for your PR.
Just to clarify the timeline: I opened PR #19716 about two weeks ago to address this issue. At the time, it hadn't been triaged as "help wanted" yet, so I was waiting for maintainers to triage and label it before following up more actively. I didn't want to ping maintainers unnecessarily, as that's not a good practice. I had also tagged you earlier to get your thoughts on the approach and coordinate to avoid duplicate work.
I see your PR uses the same core truncation logic as mine - the main difference is the amortized threshold (11 MB trigger vs 10 MB) which reduces truncation frequency. That's a nice optimization that would improve performance.
Would you be open to me incorporating that enhancement into my PR? I'm happy to collaborate to merge the best of both approaches.
Ultimately, I'm fine with whichever implementation the maintainers prefer - my main goal is just to help resolve the issue efficiently.
Happy to work together on this, thanks!!
ProthamD commentedon Mar 7, 2026
Hey @Nixxx19 , I would have agreed to if it was some other time and I have had few contributions, but I really want to make my first contribution towards Gemini CLI after giving a lot of time to understand the amortization and put it into the code,
Still I am fine with whichever maintainer chooses to merge.
Nixxx19 commentedon Mar 7, 2026
Hey @ProthamD, sorry, I didn’t realize this was your first contribution. Wish you the best of luck with it, and congrats on getting started with Gemini CLI!
ProthamD commentedon Mar 7, 2026
@Nixxx19 , Thank you, I would be really happy to collaborate with you in future if we get the opportunity , best of luck to you too.