it would be alot more powerful if codex could use gdb interactively rather than using scripting. in general, application live interactivity should be on the agenda.
Hi @mattdwells, yeah, totally get why you’re asking for that. Live debugging would make a big difference vs scripting everything.
Right now that level of interactive tooling isn’t really there, but this is exactly the kind of feedback that helps shape where things go next. I’ll pass this along so it’s logged with the team.
If you’ve got a specific workflow in mind, feel free to share it, those details usually help push things forward.
-Mark G
sure, thanks. i think how we currently queue tasks with codex by pushing [tab] is outdated and too restrictive. i think codex should be able to accept asynchronous input just like a human would and re-prioritize the tasks as it sees fit. basically everything should be made asynchronous and event based. it’s like going from the single core one cmd at a time computers of the 80s to the multi-core parallel architectures we have now. so the same codex instance should handle multiple sessions of i/o in parallel and it will interact with each seesion based on the current state. so any one session could change how it interacts with that session or any of the other sessions in real-time. so in this example, using gdb would just be one potential session. another session would be its dialogue with the human user who might be instructing it how to use gdb or what bugs to look for. of course, progressing towards supporting visual guis could be a next step, but i think you probably want to integrate interactive cmdline sessions first before going there. anyway, for sure you will do all this, it’s just a natural progression, not that my input really matters.
Hi @mattdwells, I get what you’re going for here, and it makes a lot of sense. Moving Codex toward a more asynchronous, event-driven setup where one instance can juggle multiple live sessions and reprioritize in real time feels like a pretty natural direction, especially for things like terminal workflows and interactive debugging.
Appreciate you taking the time to lay this out, the details are really helpful. I can’t share a timeline right now, but this is great context on what could make the workflow a lot more capable, and I’ll pass it along internally.
-Sunny