Kiro IDE Memory Leak — Bug Report

[kla-apisak]

Before opening, please confirm:

• I have searched for duplicate or closed issues

Operating System

macOS 26.4.1 (Build 25E253) - Chip Apple M5 Pro - RAM 48 GB

Kiro Version

0.11.131

Bug Description

After using Kiro IDE for an extended period, it consumes 81.80 GB of RAM on a machine with only 48 GB physical memory. macOS displays "Your system has run out of application memory," pauses all other applications, and the system becomes completely unresponsive until Kiro is force-quit.

Investigation shows the kiro.kiroagent extension accumulated 7.5 GB of data in ~/Library/Application Support/Kiro/User/globalStorage/kiro.kiroagent/, which may be loaded into memory and contribute to the leak.

Environment:

• macOS 26.4.1 (Build 25E253)
• Apple M5 Pro, 48 GB RAM
• Kiro v0.11.131
• Project: a monorepo (~27K source files, 4.8 GB total)

Steps to Reproduce

1. Open Kiro IDE on a monorepo project (with apps/, packages/, infra/, ios/ directories, ~27K source files)
2. Use the IDE normally for an extended period (several hours)
3. System gradually becomes sluggish
4. Eventually macOS shows "Your system has run out of application memory" with Kiro using 81.80 GB

Expected Behavior

Kiro IDE should maintain reasonable memory usage (< 4 GB) regardless of session duration. Memory should be released when no longer needed. The kiro.kiroagent globalStorage should not grow unbounded.

Conversation ID

No response

Additional Context

• Screenshot attached showing Force Quit dialog with Kiro at 81.80 GB (screenshot-memory-leak.png)
• Kiro storage breakdown on disk before cleanup:
  • kiro.kiroagent globalStorage: 7.5 GB
  • logs: 735 MB
  • Total: 8.3 GB
• Clearing ~/Library/Application Support/Kiro/User/globalStorage/kiro.kiroagent/ and restarting Kiro works as a temporary workaround
• This is similar to memory leak issues reported in other Electron-based AI IDEs (Cursor, Windsurf)

[github-actions]

🤖 Potential Duplicate Detected

This issue appears to be similar to:

• #6780: Feature Request: Storage retention/pruning settings for kiroagent globalStorage (85% similar)

What happens next?

• ⏰ This issue will be automatically closed in 3 days
• 🏷️ If this is not a duplicate, you can prevent automatic closure by adding a comment or reacting with 👎 to this message.
• 💬 Comment on the original issue if you have additional information

Why is this marked as duplicate?
Both issues report problems with kiro.kiroagent globalStorage growing unbounded and consuming excessive storage space. Issue #6780 specifically mentions the same directory path and requests storage retention/pruning settings to address the growth problem, which is directly related to the memory leak described in the new issue.

[kla-apisak]

Adding my experience — this went beyond a disk space issue and caused a full system freeze on my machine.

After extended use, the kiro.kiroagent globalStorage grew to 7.5 GB (~800+ session files). Kiro IDE ended up consuming 81.80 GB of RAM on a 48 GB machine (Apple M5 Pro, macOS 26.4.1, Kiro v0.11.131), triggering the macOS "Your system has run out of application memory" dialog and freezing the entire system.

The only workaround was force-quitting Kiro and manually deleting ~/Library/Application Support/Kiro/User/globalStorage/kiro.kiroagent/.

This really needs a retention/pruning mechanism — the unbounded growth isn't just a storage concern, it's causing OOM crashes. Would love to see this prioritized.

[github-actions]

Thank you for your feedback! 🙏

The duplicate label has been removed and this issue has been sent back for maintainer review.

A maintainer will review this issue shortly.

[kla-apisak]

any progress ?

[kla-apisak]

Any updates ? It crash time to time randomly.

[AnilMaktala]

Thank you for reporting this. The unbounded memory growth you're experiencing (81.8GB) during extended sessions is a confirmed issue that we're treating as the canonical tracker for IDE memory management.

Related reports of the same underlying problem:

• Session degrades and becomes unusable on large monorepo after sustained spec task execution — context accumulation causes progressive failure #8799 — Session degradation on large monorepos (progressive failure after 30-60 min)
• Process crash on Windows at 4GB of memory #8925 — Process crash at 4GB on Windows (hits V8 heap limit)
• "Input content length exceeds threshold" causes "An unexpected error occurred" #7730 — "Input content length exceeds threshold" errors
• Bug: New sessions auto-ingest .kiro/specs and instantly hit context limit (400k+ tokens) #4606 — Sessions auto-ingest specs and hit context limit

The root cause is that the extension host accumulates messages, tool results, and file contents in memory without eviction. We're investigating client-side memory management to properly evict stale context during long sessions.

We'll update here with progress.