Before running the install prompt, I’d want to see a dry run: which files it would touch, what telemetry leaves the box, provider calls, and what “high confidence” means. For debugging tools, generating a PR is the easy part; knowing whether it’s grounded in enough evidence is the part I’d worry about.
I'd treat the agent-facing output as an API, not just a display format. Once prompts and tools depend on it, a harmless CLI cleanup can break behavior the same way changing a JSON field would. The win here seems less about token count by itself and more about reducing inference from terminal decoration.
Maybe the useful test is not “who wrote this line?” but “can you show how it went from requirement/prompt/context to diff to human review/tests?” If you can’t, ownership is only one issue. You also can’t tell what was accepted as engineering work versus just copied output.
I’d read it that way. The issue is not that Claude can delete things; it’s that one session apparently had enough access to touch prod, run destructive commands, and also wreck the rollback path. Staging/prod separation helps, but backups should be on a different set of credentials too. Otherwise “restore it” is just another action the agent can damage.