Telegram /cas_resume is still broken on OpenClaw 2026.4.2 with plugin 0.6.0

[kesslerio]

Hi, I am still seeing /cas_resume fail on Telegram with openclaw-codex-app-server 0.6.0 on OpenClaw 2026.4.2.

I originally hit the older Telegram helper/runtime issues, upgraded from 0.5.0 to 0.6.0, and confirmed the plugin loads. The failure mode changed, but Telegram resume flows are still not usable.

What fails

These all fail in a Telegram conversation:

• /cas_resume
• /cas_resume --all
• /cas_resume --new
• /cas_resume --cwd /home/art/

What I see now in 0.6.0:

• ⚠️ Command failed. Please try again later.

Version comparison

On 0.5.0, /cas_resume got farther:

• it showed the recent thread picker
• I could select a thread
• after that, a normal message in the bound conversation caused:
  • The bound plugin OpenClaw Plugin For Codex App Server hit an error handling this message. This conversation is still bound to that plugin.

So 0.5.0 looked like:

• picker worked
• bound conversation handling crashed

On 0.6.0, the failure is earlier:

• /cas_resume itself fails before the picker/bind flow completes

So this does not look like exactly the same bug as 0.5.0. The upgrade changed the failure mode, but Telegram resume is still broken.

Environment

• OpenClaw: 2026.4.2
• Plugin: openclaw-codex-app-server 0.6.0
• Channel: Telegram
• Host: Linux / NixOS
• Codex CLI: codex-cli 0.118.0

What I already checked

• codex app-server --help works
• codex app-server itself starts
• a direct stdio JSON-RPC initialize / initialized handshake works outside the plugin
• so this does not look like "Codex app-server cannot start at all"

I also added some local tracing while narrowing it down.

What I found

I can see /cas_resume entering the plugin, with a trace like:

• codex cas_resume enter ... args="" parsed={...}

But I do not see later success-stage logs for the selection/bind flow.

Since all of these fail:

• plain /cas_resume
• --all
• --new
• --cwd ...

this looks like a shared Telegram resume/picker flow problem, not just one specific branch.

My guess is the remaining failure is somewhere around one of these:

• handleListCommand(...)
• handleStartNewThreadSelection(...)
• project/thread picker rendering
• interactive button reply delivery
• binding request / responder flow

Why I think this is different from the earlier Telegram issue

The earlier issue was the more obvious Telegram runtime-helper crash involving typing, sendMessageTelegram, etc.

This current state feels later in the flow:

• plugin loads
• command enters
• Codex app-server itself seems reachable
• but the Telegram resume flows still fail before the picker/bind flow completes

If it helps, I can also share the exact local traces and patched lines I used while narrowing this down.

[kesslerio]

I dug this further on a newer stack and split the problem into two pieces.

I opened #91 for the stale-binding half:
#91

What that PR fixes:

• if status reads hit a thread that is actually gone, the plugin clears the local binding instead of leaving the conversation stuck on a dead thread id
• if turn startup sees the same dead thread id, it drops the binding before starting the new turn
• the cleanup also removes the conversation-local pending request and callback state that would otherwise keep the topic poisoned

One important boundary: I did not treat not materialized yet as stale.

The current test suite already uses that state as a valid pre-first-message condition, so the PR keeps that behavior intact. In other words, this is meant to clean up threads that are gone, not threads that exist but have not fully materialized yet.

What it does not fix:

• the separate command-resolution problem I hit locally when an unconfigured load path fell back to bare codex
• any OpenClaw-core plugin load/provenance weirdness outside this repo

So my read now is:

• #91 is the right fix for the stale-binding part behind #81
• command resolution is still a second issue and probably deserves its own PR if we want to upstream that piece cleanly

[kesslerio]

I split the work into two small PRs instead of folding everything into one patch.

• fix: clear stale Telegram CAS bindings before reuse #91 handles the stale-binding side: dead thread ids get cleared instead of poisoning cas_status and later turns
• fix(config): prefer user-local codex binaries by default #92 handles the missing-config command side: when command is not set, the plugin now prefers a user-local codex binary before falling back to bare codex

The second piece is meant to cover the host shape I was hitting, where the working Codex install lived in a user-local bin dir but the service PATH still resolved codex to the wrong wrapper.

I kept #92 intentionally narrow: explicit command config still wins, and there are no docs changes or client spawn rewrites in that PR.

[kesslerio]

Superseded by the next comment in this thread. The updated note fixes a shell-quoting glitch in this one and has the same intended content.

[kesslerio]

I split the recent Telegram/CAS debugging into narrower upstream pieces instead of piling more onto one PR.

Current split:

• fix(config): prefer user-local codex binaries by default #92 keeps the command-resolution work isolated
• fix: normalize Telegram topic ids for inbound claim after resume #96 handles resumed Telegram topics that showed an active binding but still dropped normal inbound messages
• fix: keep plan runs active while questionnaire input is pending #95 handles the /cas_plan case where the first questionnaire prompt appears and then the active run gets cleaned up before the answer comes back

That last one now has coverage for both the plan questionnaire path and a non-plan pending-input path, since the cleanup helper is shared.

[jdm0830]

Root cause of "bound plugin did not handle this message" on regular Telegram DMs

Environment:

• OpenClaw 2026.4.20, codex CLI 0.122.0
• Plugin v0.7.0-beta.1 patched with PRs fix: clear stale Telegram CAS bindings before reuse #91, fix(config): prefer user-local codex binaries by default #92, fix: normalize Telegram topic ids for inbound claim after resume #96
• Telegram regular DM (not a topic/supergroup)

Confirmed: The codex app-server RPC is fully functional on this version — initialize, thread/list, thread/start, thread/resume, and thread/read all work correctly via stdio.

Sequence leading to the error:

1. Plugin has an auto-approved binding on restart
2. The bound thread is stale — readThreadState returns no rollout found for thread id
3. ensureUsableBindingForTurn → clearStaleBinding → unbindConversation clears the binding but sends no message to the user
4. handleInboundClaim gets null from hydrateApprovedBinding → resolvedBinding is null → returns { handled: false }
5. OpenClaw sees the plugin was bound but returned false → shows "The bound plugin did not handle this message"

The fix: When handleInboundClaim returns { handled: false } after clearing a stale binding, it should first send the user a message like:

⚠️ Session expired. Run /cas_resume to start a new thread.

This way the user knows what to do, and OpenClaw does not show the error. Alternatively, ensure detachConversationBinding is called before returning { handled: false } so OpenClaw unregisters the plugin claim and routes to the fallback agent instead.

[jdm0830]

Follow-up: implementation details and a second bug found

After implementing the fix described above, two additional findings worth documenting:

---

Fix implementation: correct API for checking active OpenClaw bindings

The natural approach of this.api.runtime.channel.bindings.resolveByConversation() does not work — bindings is not a property on PluginRuntimeChannel. The actual API is getSessionBindingService() from openclaw/plugin-sdk/session-binding-runtime:

import { loadOpenClawCompatModule } from "./openclaw-sdk-compat.js";

private async loadSessionBindingService() {
  const mod = await loadOpenClawCompatModule<{
    getSessionBindingService: () => {
      resolveByConversation: (ref: ConversationRef) => { bindingId: string } | null;
      unbind: (input: { bindingId: string; reason?: string }) => Promise<unknown>;
    };
  }>({
    specifier: "openclaw/plugin-sdk/session-binding-runtime",
    fallbackRelativePath: "dist/plugin-sdk/session-binding-runtime.js",
    label: "session-binding-runtime",
    logger: this.api.logger,
  });
  return mod.getSessionBindingService();
}

In handleInboundClaim, when resolvedBinding is null:

const sessionBindingSvc = await this.loadSessionBindingService().catch(() => null);
const activeBinding = sessionBindingSvc?.resolveByConversation(conversationRef) ?? null;
if (activeBinding) {
  this.api.logger.warn(`codex inbound claim detaching stale openclaw binding ...`);
  await sessionBindingSvc!.unbind({ bindingId: activeBinding.bindingId, reason: "stale-cleared" })
    .catch(() => undefined);
  await this.sendText(conversation, "⚠️ Codex session expired. Run /cas_resume to start a new thread.")
    .catch(() => undefined);
  return { handled: true };
}
return { handled: false };

---

Second bug: conversation key mismatch on Telegram DMs

Even after the stale binding fix, messages kept hitting { handled: false } because the plugin's key for the same Telegram DM conversation was inconsistent between the command path and the inbound path.

Root cause: toConversationKey includes parentConversationId for Telegram:

channel === "telegram" ? (target.parentConversationId?.trim() ?? "") : ""

• Command path (/cas_resume → toConversationTargetFromCommand): sets parentConversationId = undefined for DMs (no messageThreadId) → key = telegram::default::5018095404::
• Inbound path (handleInboundClaim → toConversationTargetFromInbound): OpenClaw supplies parentConversationId = "5018095404" for all Telegram messages → key = telegram::default::5018095404::5018095404

The binding is stored under the command-path key but looked up under the inbound-path key — they never match, so every inbound message returns { handled: false }.

Fix: In toConversationTargetFromInbound, for Telegram DMs (no topic thread), explicitly set parentConversationId = undefined to match the command path:

const parentConversationId =
  channel === "discord"
    ? normalizeDiscordConversationId(event.parentConversationId)
    : channel === "telegram"
      ? telegramThreadId != null
        ? normalizeTelegramChatId(event.parentConversationId) ??
          normalizeTelegramChatId(conversationIdRaw)?.split(":topic:")[0]
        : undefined  // DM: no topic — parentConversationId not needed for key matching
    : event.parentConversationId;

This was the deeper reason messages were never claimed by the plugin on Telegram DMs. The stale binding fix alone is not sufficient without this correction.