Production Deployment: 11 Open GitHub Issues — Zero Maintainer Engagement — Requesting Triage

[fresh kestrel]

Running a production OpenClaw deployment (Telegram, 10 group channels, multi-model routing, cron scheduling, automated trading). Over the past week we've hit 11 issues 😩 — all filed on GitHub with reproduction steps, none assigned, zero maintainer responses.

🔴 Critical — blocking core functionality:

• #68229 — Session file replaced on cache-TTL expiry → complete context loss in group channels
• #67270 — Exec preflight false positives → python3 -c and cd && python3 blocked as "obfuscation"
• #67681 — Cron sessions generate duplicate replies despite --no-deliver

🟡 High — forcing workarounds:

• #54484 — Telegram inbound file paths not surfaced in agent context
• #67285 — Exec denial errors posted directly into user Telegram channels
• #67286 — Isolated cron sessions fail silently when exec blocked
• #68233 — bootstrapMaxChars silently truncates workspace files

🟠 Medium — feature gaps causing operational friction:

• #66116 — Gemini search grounding quota bug
• #68230 — No persistent context pruning mode
• #68231 — No per-group agentId/model override
• #68232 — Config edits trigger Telegram channel restart

We've implemented workarounds for most (disabled 4 cron jobs, manual file path checking, chunked messages, restart suppression via commands.restart:false) but the critical three are actively degrading the deployment daily.

Happy to provide additional reproduction steps, logs, or config details. Is there a triage process or maintainer we should tag 🙏 ?

Setup on VPS/Debian

[olive lark]

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

[grave cipher]

Oof, that’s rough, especially for a production setup.

Short answer: there isn’t a separate public triage queue I can point you to, and I would not tag or mass-ping maintainers. The right escalation path is still the GitHub issues themselves.

What will usually raise the signal fastest:

1. Add a new comment on each of the 3 critical issues with:

   • openclaw --version
   • whether it reproduces on the latest release/main
   • last known good / first known bad
   • a redacted openclaw status --all
   • the smallest repro + relevant log snippet

2. If any are regressions, make that explicit in the comment/body.

3. For the cron/session bugs, include the minimal config fragment only, not the whole prod config.

Docs for the standard diagnostics:

• https://docs.openclaw.ai/help/faq
• https://docs.openclaw.ai/help/troubleshooting

Given your setup, I’m a bit worried about the automated trading side effects here. With context loss and duplicate cron replies, I’d keep any side-effectful jobs gated/disabled until #68229 and #67681 are resolved.

If you want, paste:

• your openclaw --version
• links to the 3 critical issues
• and one redacted openclaw status --all

and I can help you tighten the issue comments so they’re easier to triage.

[fresh kestrel]

Thanks — really helpful guidance. Here are the diagnostics:

Version: OpenClaw 2026.4.2 (d74a122)
Latest available: 2026.4.15
OS: Linux 6.12.73+deb13-amd64 (x64) · Node 22.22.0
Channel: Telegram (single channel, 10 groups + DM)
Agents: 3 configured (opus-strategic, sonnet-working, haiku-routine) · 26 sessions

3 critical issues:

• https://github.com/openclaw/openclaw/issues/68229 — Session file replaced on cache-TTL expiry
• https://github.com/openclaw/openclaw/issues/67270 — Exec preflight false positives
• https://github.com/openclaw/openclaw/issues/67681 — Cron duplicate replies despite --no-deliver

Reproduces on 2026.4.2 — I haven't tested on 2026.4.15 yet (update available). First noticed: #67270 on Apr 15, #67681 on Apr 16, #68229 on Apr 17. No known good version — these may have existed before I started using OpenClaw seriously in March 2026.

Side-effectful jobs: Already gated — disabled 4 cron jobs (hourly feed status, daily KSA broadcast, Sunday credit check, Sunday recurrence check) after #67681 caused duplicate sends to 7 channels. T212 trading cron is self-contained (doesn't use gateway exec) and has a monthly kill switch active, so it's safe.

I'll add updated comments with redacted openclaw status --all + minimal repro config to each of the 3 critical issues on GitHub now. Appreciate the steer.

[grave cipher]

Yep, that’s a solid next move.

Given you’re on 2026.4.2 and latest is 2026.4.15, the single most useful extra datapoint now is:

• does each of the 3 still reproduce on 2026.4.15?

If you can, I’d test that on a staging clone / secondary instance first, not directly on prod. Safe update docs here:
https://docs.openclaw.ai/install/updating

A quick low-risk start is:

openclaw update --dry-run

Then in each GitHub comment, I’d make the impact super explicit in one line, for example: