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.