This week I came up with a fun trick of using Claude Code as a "second pair of eyes" for debugging - and, it could apply to *any* CLI interaction - so, whether you are writing code or using ssh to configure routers, you might find useful. It has two parts to it:
In my experiment, what I was debugging was a pretty tricky crash in my hobby project, where i ended up with the CPU attempting to execute address of 0 and an entirely corrupt stack - a beautiful challenge. In this "pair" setup, despite me quite often have to dissuade Claude from doing "continue" ("don't you remember we will end up with a corrupt stack if we do this ?"), and the session being a long sequence of fairly laborious "stepi" and "finish" gdb commands, interspersed with disassembly and "info registers", the result was an overwhelming success: catching the seemingly innocuous code in my syscall implementation redhanded, corrupting the stack of the user program performing the syscall... actually, it didn't happen immediately - as I didn't believe it was a problem, we first had a little argument about it !
Claude was pretty useful in letting me get lazy with various pointer calculations, and concentrate on ensuring that the speculations that it came up with during the session actually matched the reality.
"You are saying we are already inside libc initialization, but the subroutine that we just traced is called dl_printf - so we probably aren't there yet?" - and similar, relatively obvious guardrails. (Yes, I had the function names off dynamic linker and libc, because the crash was very early, so I built my own version of ld.so and glibc, for more convenience).
So, I thought to share it and see - please leave some comments with your stories if you find it useful! :-)
The obvious warning that nonetheless never hurts: keep in mind that you don't control which part of the log Claude will see; so you may want to avoid having confidential information in there.
../ HEADER.txt 06-Jul-2025 22:39 2705