If you are running local LLMs, your hard drive is likely bleeding gigabytes without you realizing it. Between default model weights, duplicate quantization formats, and forgotten vector embeddings, local AI setups are silent storage hogs.

Here is how you can systematically track down and clean up the clutter directly from your terminal:

• Locate hidden Hugging Face and Ollama model weights: By default, Hugging Face caches everything in ~/.cache/huggingface/hub and Ollama stores models under ~/.ollama/models. Run du -sh ~/.cache/huggingface/ to see how much space is currently locked up.
• Prune redundant quantization formats and unused embedding databases: Review your downloaded models and delete redundant variations (like keeping both Q4_K_M and Q8_0 when you only use one). Clear out stale Chroma, FAISS, or Pinecone local vector database caches residing in your project directories.
• Automate routine garbage collection: Set up a lightweight shell script to periodically check cache growth and alert you before your drive hits capacity.

Fore More Information

I put together the complete, production-ready automated cleanup script along with an interactive storage calculator to help map out your directories.

Direct links to the complete article.

drop a comment below

Based on the technical breakdown Intezer and Kodem Security published July 19, here's the architectural impact for anyone running Kiro or evaluating agentic IDEs.

Root cause: ~/.kiro/settings/mcp.json wasn't in Kiro's protected-paths list. The agent's fsWrite tool could modify it without a real approval gate, and the file auto-reloads on change, starting whatever MCP server it describes.

Attack: hidden color:#fff;font-size:1px text on a normal-looking doc page instructs Kiro to add an MCP server whose launch command is an inline Node.js exfil script. Developer only approved fetching the URL. Everything downstream — file write, server creation, code exec — happened silently.

Fixed in 0.11.130. No CVE issued. Worth noting this is the second time this exact file-write primitive has surfaced in Kiro since its 2025 launch — the first fix only covered Supervised mode, leaving default Autopilot exposed, which is what got hit this time.

Full writeup w/ attack-chain diagram and remediation list: [background link, footnote]

Anyone running agentic IDEs in Autopilot-equivalent modes in production — what's your actual control for file writes to tool/MCP config paths? Approval dialogs clearly aren't sufficient on their own.

https://www.techgines.com/post/aws-kiro-mcp-prompt-injection-vulnerability