I wanted to briefly show how I'm using screen for debug sessions and that was a little bit motivated because Mario showed that he wrote this MCP server that can manage processes behind the scenes and for what it's worth I think it's a good use of MCP. But I also kind of wanted to just show how much Claude can do out of the box if you just give it the right tools.

So I have a program here with segfaults and it's a program that Claude wrote where I made afterwards a bug into it. I added an off by one somewhere. And really the only thing that I have here is I added into my Claude MD file that when debugging use LLDB in a well-known screen it should call the screen like this and when it's done debugging it should close the screen again and then to send strings into the it should use the $string syntax.

That is kind of I think the main thing that it needs to be successful. Anyways that's the idea. So what I first want to do is I wanted to tell it to run the program. So in this folder we have a program which segfaults when you run it. You can run it with make run.

Please reproduce the crash. And I'm not sure what's going on. I think I might have turned on something here. I'm not sure why it took so long. Oh yeah because it's the first time I've run it. Okay. So let's do that. And then it should basically just run this program and see a segfault call.

So far so good. Now I want you to debug this with LLDB. And afterwards I want you to fix the bug and run it again. Okay. So if you're not familiar with what screen is, it's a new program. There's another one called Tmux. But I think screen might be installed on all machines.

I'm not sure. Anyways, I just happen to use screen. I think it might also have a little bit more of a training data for screen. So I will just attach to the screen here just to watch it so we can see what it's doing. So it has already started screen here.

Now I tried to run, I had to run, run straight away, but didn't actually start LLDB. So it terminated my screen. Oh, that's not good. So now I have a new one. Let's reconnect. Okay. So now we have a screen that just runs LLDB. Seemingly that's what it wanted to do.

and it has created the target, which means it's going to run this program. But it didn't, didn't actually run it. It's eventually going to figure out how it's going to run it. So in this case, it needs my password because I've done this yet. I don't know. Okay. But we have reached the point where it is now looking at the backtrace.

no variables here seemingly. We might actually have compiled this without debug. So afterwards I will, I will compile it with a debug flag. I think it will make it a little bit more useful. But it has identified the bug. Now it's going to recompile it. And run make it worked.

And it's done. And that's going to kill the screen. So this is just to show it can do that. Right. And I, in general, I think like it's, it's just kind of fun to, to give it access to these tools, which are, what it has a lot of training data on.

I think it has learned a ton about screen over the years, that it's able to remote control a program like this. And yeah, that's, that's basically all I wanted to show, which is it can run screen to remote control text debugger and can do quite well.