Problem

createTypingCallbacks guards onReplyStart with the closed flag, but fireStart itself has no such guard. If a keepalive tick is already in-flight when fireStop runs, the async onTick → fireStart callback still completes and calls params.start() (i.e. sendChatAction('typing')) after the reply message has already been delivered.

On Telegram — which has no cancel-typing API — this causes the typing indicator to linger ~5 seconds after the bot's message appears.

Timeline of the race

T=0.0s  keepalive tick fires → fireStart() begins (async, in-flight)
T=0.1s  reply message delivered
T=0.2s  fireStop() → closed=true, keepaliveLoop.stop()
T=0.3s  fireStart() completes → sendChatAction('typing') sent  ← BUG
T=5.3s  Telegram typing indicator finally expires

Fix

Add if (closed) return at the top of fireStart as defense-in-depth:

const fireStart = async () => {
  if (closed) return;  // ← added
  try {
    await params.start();
  } catch (err) {
    params.onStartError(err);
  }
};

This ensures that even an in-flight keepalive tick is suppressed once cleanup has started.

Scope

One-line change in src/channels/typing.ts. No new dependencies, no config changes.

Greptile Summary

Adds defense-in-depth guard to fireStart to prevent race condition where in-flight keepalive ticks send typing indicators after cleanup. This complements the closed flag guard added to onReplyStart in a0fa283, closing the gap for async callbacks that are already executing when fireStop runs.

Confidence Score: 5/5

• This PR is safe to merge with minimal risk
• Single-line defensive guard that directly addresses a documented race condition. The fix follows existing patterns in the codebase (same guard is used in onReplyStart), has clear scope, and introduces no new dependencies or side effects. Existing tests cover the typing lifecycle behavior.
• No files require special attention

_{Last reviewed commit: bf6240f}

_{(3/5) Reply to the agent's comments like "Can you suggest a fix for this @greptileai?" or ask follow-up questions!}