Seems to be a very regular occurrence starting around this time of day (14:30 UTC)...
Claude Code returning: API Error: 500 {"type":"error","error":{"type":"api_error","message":"Internal server error"},"request_id":"---"}
Over and over again!
1,516 karma · joined October 20, 2017
Claude Code returning: API Error: 500 {"type":"error","error":{"type":"api_error","message":"Internal server error"},"request_id":"---"}
Over and over again!
The problem: agents like Claude Code, Codex, and Aider execute file reads, shell commands, and network requests with your full system privileges.
For example, when a malicious README tells the agent to read ~/.ssh/id_rsa and POST it somewhere, nothing in the agent's own trust model catches it. Auto Mode makes this worse - it asks the model to audit its own actions, so a prompt injection that corrupts the reasoning also corrupts the permission layer.
grith wraps any CLI agent with `grith exec -- <agent>`. Every syscall passes through a multi-filter scoring engine before it executes. Deterministic, ~15ms overhead, no LLM reasoning in the permission path. Linux now, macOS/Windows coming. AGPL, open-core.
Two weeks ago a DPRK-linked attacker backdoored axios on npm (400M monthly downloads). The RAT executed 1.1 seconds into npm install. AI agents run npm install autonomously, without human review. If yours ran it during the 3-hour window, you're compromised and nobody told you.
That's the threat model grith is built for.
Readership, clicks and views
I do find Codex very good at reviewing work marked as completed by Claude, especially when I get Claude to write up its work with a why,where & how doc.
It’s very rare Claude has fully completed the task successfully and Codex doesn’t find issues.
I’ve found Claude in particular to be very good at this sort of thing. As for whether it’s a good thing, I’d say it’s a net positive - your own reporting of this probably saved a bigger issue!
We wrote up the why/what happened on our blog twice… the second based on the LiteLLM issue:
https://grith.ai/blog/litellm-compromised-trivy-attack-chain
It’s really interesting to read how you’ve captured and created these images… will follow your work!
We tried to connect the February 27, 2026 Trivy CI compromise to the later Trivy release/tag issues, the trivy-action poisoning, the npm/Checkmarx follow-on activity, and finally the LiteLLM 1.82.7/1.82.8 package on March 24 2026!
What made it look like one campaign to us was the repeated overlap in operator attribution, payload structure, and artifacts like tpcp.tar.gz, plus the LiteLLM maintainer saying it appears to have come from Trivy in their CI/CD.
If anyone spots gaps or overreach in the timeline, I’d be interested in corrections.
We’ve covered so many issues already on our blog (grith.ai)
The extension's payload targeted five AI coding agents (Claude Code, Codex, Cursor, Windsurf, Copilot) with tool-specific flags to bypass their permission systems. First documented case of an AI agent attacking a supply chain and then using the compromised artifact to target other AI agents. CVE-2026-28353, CVSS 10.0.
As you say lots of effort going into this problem at the moment. We launch soon with grith.ai ~ a different take on the problem.
The problem: every agent (Cline, Aider, Codex, Claude Code) has unrestricted access to your filesystem, shell, and network. When they process untrusted content — a cloned repo, a dependency README — they’re prompt injection vectors with full machine access. No existing tool evaluates what the agent actually does at the syscall level.
grith wraps any CLI agent without modification. OS-level interception captures every file open, network call, and process spawn, then runs it through 17 independent security filters in parallel across three phases (~15ms total). Composite score routes each call: auto-allow, auto-deny, or queue for async review. Most will auto approve - which eliminates approval fatigue.
Also does per-session cost tracking and audit trails as a side effect of intercepting everything.
Taking more of an automated supervisor approach with limited manual approval for edge cases.
Grith.ai
Everything is done locally via our grith cli tool.
Happy to answer any questions on hello@grith.ai too
Sandboxing alone isn’t the right approach… a multi-faceted approach is what works.
What we’ve found that does work is automation on the approval process but only with very strong guards in place… approval fatigue is another growing problem - users simply clicking approve on all requests.
The VC money is there until they can solve the optimization problems