I liked the idea of controlling Codex and Claude Code from Telegram and Feishu.

I did not like what happened after the first task finished.

I'd ask for a change like "make the button green" or "retry that one", and my gateway would sometimes start a brand-new runtime with the wrong assumptions instead of continuing the work that had just happened.

That sounds small until you use it on a phone. On mobile, follow-up messages are short, vague, and full of implied context. If the system forgets the last task, the whole experience turns into "re-explain everything in one sentence."

The annoying failure mode

The setup was already pretty good:

• /cx <task> starts Codex
• /cc <task> starts Claude Code
• plain follow-up messages keep using the current runtime session

The breakage showed up after the active session was no longer the obvious routing target.

For example:

1. I send /cc create a login page
2. Claude Code finishes
3. I send make the button green

What I actually mean is obvious: continue the work that just finished, preferably with the same provider.

What many chat-style integrations do instead is one of these:

• treat that sentence as a brand-new task with no memory
• send it to the default provider instead of the previous one
• forward status questions like progress back into the runtime as if they were coding prompts

That is tolerable on desktop. On Telegram, it is miserable.

The fix was not "more prompt magic"

I first thought this was a prompt problem.

It was not.

The real issue was that the channel layer needed a small structured memory about the conversation's most recent task, even after the runtime session had ended or detached.

So in CliGate, I added a remembered supervisor path built around a per-conversation brief:

• task title
• provider
• last known status
• summary/result/error
• next suggestion

That brief becomes the thing the channel gateway can reason from when the user sends a messy mobile follow-up.

What changed in practice

Now the system distinguishes between a few high-confidence follow-up intents:

• "continue what we were doing"
• "retry that"
• "go back to the previous task"
• "start a related sibling task"

One of the small routing pieces looks like this:

if (isDescriptiveTaskFollowUp(input) || isNaturalLanguageTaskContinueIntent(input)) {
  return {
    originKind: 'remembered_follow_up',
    reuseTaskIdentity: true
  };
}

That alone is not enough, so the remembered path also carries source-task context forward:

if (originKind === 'remembered_follow_up' && sourceTitle) {
  return `Continuing remembered task "${sourceTitle}" with a fresh execution.`;
}

The important part is the behavior, not the string:

• if the old runtime is gone, start fresh with remembered context
• prefer the same provider that handled the original task
• keep the relationship to the source task explicit

That last part matters more than I expected. Once the new execution records that it came from a remembered follow-up, later status replies and wrap-ups can explain what it is actually continuing.

Mobile follow-ups became much less fragile

After that change, these messages stopped feeling random:

make the button green
另外再做一个：生成部署说明
retry that
return to the previous task
progress
summarize

Some of them should continue work. Some should start a related task. Some should never touch the runtime at all.

For example, CliGate now answers natural-language status questions from remembered task state when possible, instead of blindly forwarding progress or done? into Codex or Claude Code as if those were user prompts for code generation.

That sounds obvious, but it only becomes reliable once the channel conversation stores a durable supervisor brief.

I also had to preserve provider preference

This was another subtle bug.

Say the last successful task ran on Claude Code, but the conversation's default provider is Codex. If the user sends:

把按钮改成绿色

I do not want the channel gateway to silently fall back to the default provider just because the previous session has ended.

So remembered follow-ups prefer the last provider when that intent is high-confidence.

I pinned that with a unit test that effectively checks:

assert.equal(followUp.type, 'runtime_started');
assert.equal(followUp.provider, 'claude-code');
assert.equal(followUp.startedFresh, true);

That was the difference between "this remembers my workflow" and "this is just a chatbot with commands."

The UX outcome I actually wanted

The goal was simple:

• use /cx or /cc to start work explicitly
• keep plain-language follow-ups natural
• let status/wrap-up questions be answered from task memory
• avoid forcing users to restate the previous task on mobile

This is now built into CliGate's channel layer for Telegram and Feishu, along with conversation records in the dashboard so I can inspect what the gateway thought the task context was.

That combination ended up being more useful than I expected:

• mobile keeps the fast, messy input style people actually use
• the dashboard keeps the execution history inspectable
• the supervisor layer has enough structure to avoid random session drift

If you're building AI tooling over chat, this is the part to not fake

A lot of agent demos look good as long as every message is a fully specified instruction.

Real usage is mostly:

• "continue that"
• "change this part"
• "retry"
• "what happened?"

If your system cannot survive those messages, it does not really remember the work. It only remembers the last prompt.

If you want to see how I implemented it, the project is here:

https://github.com/codeking-ai/cligate

I'm curious how other people are handling mobile follow-ups for coding agents. Are you keeping strict session binding, remembered task summaries, or something else entirely?