"My Coding Agent Finished the Task. Why Did the Thread Die?"

A developer building CliGate, a local control plane for coding agents, identified a bug where task completion was incorrectly terminating the entire conversation thread instead of just the current turn. By separating the concepts of conversation, runtime session, and turn, the fix ensures that follow-up messages retain context, making the agent feel more conversational. The developer argues that treating completion as session death breaks the user experience, especially on mobile or chat platforms where short follow-ups rely on preserved context.

The most annoying follow-up bug in a coding agent is not a crash. It is when the first task succeeds, and the next message still feels like amnesia. I would ask Claude Code or Codex to do something through my local assistant, wait for it to finish, and then send the most normal follow-up in the world: make the button green From the user's side, that is obviously part of the same thread. From the system side, it was too easy to treat completed as "this session is over, start from scratch next time." That was the bug. While building CliGate, I realized I had let three layers blur together: Those are not the same object. A conversation is the long-lived place where the user keeps talking. A runtime session is the working thread attached to that conversation. A turn is just one run inside that session. Once I wrote it down that way, the mistake became obvious. completed should mean the current turn is done. It should not mean the whole thread has to be detached. The broken flow looked like this: php user asks for task - runtime session starts - task completes - conversation clears active session - next follow-up starts a brand-new session That does not sound terrible until you use it from a phone or a busy web chat. Real follow-ups are short. People say things like: Those messages only work if the agent still knows what thread they belong to. If the system detaches the session the second one task finishes, the user is forced back into full restatement mode. The agent technically works, but the thread feels fake. My first instinct was to improve follow-up classification. That helped a little, but it was not the core fix. The real fix was to make the binding model explicit: In other words, I stopped treating task completion as session death. That tiny semantic change affects the whole product feel. Not every follow-up should reuse the old session forever. But the boundary needs to be meaningful. In CliGate, the cases that justify a new session are things like: That is very different from saying the last turn completed, so the thread should be thrown away. The first rule matches how people think. The second rule matches how brittle plumbing thinks. The nice part is that the same model applies in more than one place. In a web chat window, the user expects one tab to behave like one ongoing thread. In Telegram, Feishu, or DingTalk, the expectation is even stronger. A conversation on the phone is already compressed. The user is relying on the system to preserve context across tiny, vague follow-ups. So the product behavior I wanted was simple: completed or failed do not silently drop the thread /new or a real config drift can start a fresh sessionThat makes the agent feel much closer to a real working thread instead of a command launcher. Once you separate conversation, session, and turn, the UI gets easier to reason about too. The user can understand: That is a much better mental model than making the user guess whether the tool still remembers anything. It also makes debugging easier. If a new session appears, it should be because the user asked for one or because something important changed, not because the state machine quietly treated success as disposal. If you are building a coding agent, do not let one successful task kill the thread. The durable unit is the conversation. The reusable worker is the runtime session. The thing that ends on success or failure is the turn. Once I separated those three layers, follow-ups stopped feeling random and started feeling conversational. That is now part of how I am shaping CliGate https://github.com/codeking-ai/cligate , the local control plane I use for Claude Code, Codex CLI, Gemini CLI, channels, and a resident assistant layer on top. If you are building agent workflows, are you treating completion as the end of a turn, or the end of the whole thread?