Here's the draft PR: https://github.com/xbmc/xbmc/pull/28404

And yes, it correctly diagnosed the problem - I confirmed this morning. The cache had been partially deleted (exactly like it said) and the patched version of the software automatically detected this and rebuilt the cache rather than crashing. This was using the initial version of the patch from commit 1 of the PR.

I then talked with Claude a bit to come up with a less hacky solution that doesn't require constant cache rebuilding, and it suggested writing the "cache" to no_backup, bypassing the cache trimmer. However, this required rebuilding the .so via NDK, so it spun up a full VM in multipass, installed all the tools in there to build the fully patched APK, and built it (the VM was my suggestion, it was about to just brew install everything and mess with my local dev environment).

You can read the full log here, it's nuts: https://github.com/user-attachments/files/28659274/2026-06-0...

I think the key takeaway from this experience (and a few others recently) is that Claude Code works much, much better when you explicitly instruct it to test against real data.

Had I simply described the issue and asked it to think up a solution it likely would have just navel-gazed and then come up with a wrong solution. But by pointing it at a real working environment and actively encouraging it to get its hands dirty, it found the actual solution rapidly - in spite of the fact that I gave it wrong information twice.