Best possible solution:

Land the focused shared-helper fix after exact-head validation if maintainers accept one final duplicate stop as the cleanup contract for pending persistent starts.

Do we have a high-confidence way to reproduce the issue?

Yes. Current main clearly allows cleanup to run before Feishu records typingState, so the first stop can no-op and the later successful start can leave persistent typing behind.

Is this the best way to solve the issue?

Yes, with maintainer acceptance of the compatibility risk. Serializing cleanup in the shared helper is narrower than a Feishu-only patch and keeps typing start off the reply critical path while adding regression coverage.

AGENTS.md: found and applied where relevant.

Codex review notes: model gpt-5.5, reasoning high; reviewed against bbc4bee7a22b.

Label changes:

• add rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🌊 off-meta tidepool and patch quality is 🐚 platinum hermit.
• remove rating: 🦐 gold shrimp: Current PR rating is rating: 🐚 platinum hermit, so this older rating label is no longer current.

Label justifications:

• P2: The PR addresses a normal-priority user-visible channel cleanup regression with limited blast radius.
• merge-risk: 🚨 compatibility: The shared plugin-SDK-exported typing helper now permits a duplicate stop call in the pending-start cleanup race.
• rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🌊 off-meta tidepool and patch quality is 🐚 platinum hermit.
• status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Not applicable: This is a ClawSweeper bot repair PR, so the external-contributor real behavior proof gate does not apply; the PR body reports focused tests and a source-level race probe.

PR surface:

Source +59, Tests +90. Total +149 across 2 files.

What I checked:

• Current main race window: Current main starts typing in the background, resumes after one microtask, and cleanup sends only one stop without waiting for the start to settle. (src/channels/typing.ts:95, bbc4bee7a22b)
• Feishu persistent cleanup contract: Feishu assigns removable typing state only after addTypingIndicator resolves, and stop returns without action while typingState is still unset. (extensions/feishu/src/reply-dispatcher.ts:189, bbc4bee7a22b)
• PR repair approach: The PR tracks pending starts and calls sendStop(true) after a successful pending start settles when cleanup already requested a stop. (src/channels/typing.ts:64, 13725651dca8)
• Regression coverage: The PR adds Feishu-style persistent typing and keepalive pending-start cleanup tests that require the final post-start stop. (src/channels/typing.test.ts:240, 13725651dca8)
• Plugin SDK exposure: createTypingCallbacks is exported through channel-outbound, so behavior changes affect built-in channels and plugin SDK consumers, not only Feishu. (src/plugin-sdk/channel-outbound.ts:28, bbc4bee7a22b)
• Latest release still has the race: v2026.5.28 contains the same fire-and-forget start and one-shot stop behavior, so the fix is not already shipped. (src/channels/typing.ts:95, e93216080aa1)

Likely related people:

• obviyus: Commit 45b8645 made typing starts fire-and-forget in the shared and auto-reply typing paths that this PR is repairing. (role: introduced behavior under review; confidence: high; commits: 45b86450795d; files: src/channels/typing.ts, src/auto-reply/reply/typing.ts, src/channels/typing.test.ts)
• Peter Steinberger: Recent current-main history and blame show normalization/refactor work touching the same typing helper and Feishu typing paths. (role: recent area contributor; confidence: medium; commits: 00d8d7ead059, 340247731416; files: src/channels/typing.ts, src/auto-reply/reply/typing.ts, extensions/feishu/src/reply-dispatcher.ts)
• zhuisDEV: Related merged Discord reply typing lifecycle work provides sibling-channel context for typing cleanup behavior. (role: adjacent typing lifecycle contributor; confidence: medium; commits: 6f20f29688d7; files: extensions/discord/src/monitor/reply-typing-feedback.ts, extensions/discord/src/monitor/message-handler.ts)

• 🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
• 🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
• 🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
• 🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
• 🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
• 🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
• 🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.