openclaw - ✅(Solved) Fix Telegram: image/photo attachments fail with "Something went wrong" after 2026.4.x update [2 pull requests, 4 comments, 3 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#59956Fetched 2026-04-08 02:38:19
View on GitHub
Comments
4
Participants
3
Timeline
8
Reactions
0
Author
Timeline (top)
commented ×4cross-referenced ×2closed ×1locked ×1

Sending any image via Telegram results in a generic error response: "Something went wrong while processing your request. Please try again."

This began after updating from 2026.3.31 → 2026.4.2. Images were working prior to the update.

Error Message

Sending any image via Telegram results in a generic error response: "Something went wrong while processing your request. Please try again." Error is returned immediately. No image-related entries appear in the gateway log — the image does not reach the model at all, suggesting the failure is in the media handling pipeline before the model call.

  • No image-related errors appear in gateway log — error occurs before logging

Root Cause

Sending any image via Telegram results in a generic error response: "Something went wrong while processing your request. Please try again."

This began after updating from 2026.3.31 → 2026.4.2. Images were working prior to the update.

Fix Action

Workaround

None currently known. Rolling back to 2026.3.31 would likely restore functionality.

PR fix notes

PR #59963: fix(telegram): keep inbound images readable on upgraded installs

Description (problem / solution / changelog)

Summary

  • Problem: Telegram image attachments can fail on upgraded installs where the active state dir still resolves to the legacy ~/.clawdbot tree while inbound media is saved under ~/.openclaw/media.
  • Why it matters: the hardened local-media allowlist rejects the saved image path, so Telegram photo-only turns can fail before the image reaches media understanding or the model.
  • What changed: src/media/local-roots.ts now trusts the managed config-dir media cache in addition to the active state-dir roots, and src/media/local-roots.test.ts adds a regression test for the legacy/new dir split.
  • What did NOT change (scope boundary): this does not widen local media reads beyond OpenClaw-managed directories and does not change Telegram download behavior itself.

Change Type (select all)

  • Bug fix
  • Feature
  • Refactor required for the fix
  • Docs
  • Security hardening
  • Chore/infra

Scope (select all touched areas)

  • Gateway / orchestration
  • Skills / tool execution
  • Auth / tokens
  • Memory / storage
  • Integrations
  • API / contracts
  • UI / DX
  • CI/CD / infra

Linked Issue/PR

  • Closes #59956
  • Related #59956
  • This PR fixes a bug or regression

Root Cause / Regression History (if applicable)

  • Root cause: inbound media writes already target resolveConfigDir()/media, but the local-media allowlist only trusted roots derived from resolveStateDir(). On upgraded installs those can diverge (~/.clawdbot vs ~/.openclaw), so the just-saved Telegram image path was treated as outside the allowed roots.
  • Missing detection / guardrail: there was no regression coverage for the legacy-state/new-config split in media local-root resolution.
  • Prior context (git blame, prior PR, issue, or refactor if known): the user report in #59956 points at the 2026.4.x hardening changes; this fix stays in the hardened path and narrows the compatibility gap instead of weakening the policy.
  • Why this regressed now: stricter local-media path validation made the state-dir/config-dir mismatch observable for Telegram inbound images.
  • If unknown, what was ruled out: ruled out Telegram getFile/download failures because the failing path is after media save and before media understanding/model handoff.

Regression Test Plan (if applicable)

  • Coverage level that should have caught this:
    • Unit test
    • Seam / integration test
    • End-to-end test
    • Existing coverage already sufficient
  • Target test or file: src/media/local-roots.test.ts
  • Scenario the test should lock in: a legacy state dir and new config dir can diverge, but inbound media must still be readable from the managed config-dir media cache.
  • Why this is the smallest reliable guardrail: the bug is in local-root resolution, so the direct root-merging test covers the exact regression without adding a heavier Telegram harness dependency.
  • Existing test that already covers this (if any): None.
  • If no new test is added, why not: N/A

User-visible / Behavior Changes

  • Telegram image/photo turns on upgraded installs with legacy state-dir layouts can reach media understanding/model processing again instead of failing early.

Diagram (if applicable)

Before:
Telegram photo -> save under ~/.openclaw/media -> allowlist trusts ~/.clawdbot roots only -> attachment read blocked -> request fails

After:
Telegram photo -> save under ~/.openclaw/media -> allowlist trusts managed state-dir + config-dir media roots -> attachment read succeeds -> request proceeds

Security Impact (required)

  • New permissions/capabilities? (Yes/No) No
  • Secrets/tokens handling changed? (Yes/No) No
  • New/changed network calls? (Yes/No) No
  • Command/tool execution surface changed? (Yes/No) No
  • Data access scope changed? (Yes/No) No
  • If any Yes, explain risk + mitigation:

Repro + Verification

Environment

  • OS: macOS
  • Runtime/container: Node 24 / pnpm workspace
  • Model/provider: N/A for the regression test
  • Integration/channel (if any): Telegram
  • Relevant config (redacted): upgraded install with legacy state dir still resolving to ~/.clawdbot

Steps

  1. Start from an upgraded install where resolveStateDir() still resolves to the legacy state tree.
  2. Receive a Telegram photo so inbound media is saved under the managed config-dir media cache.
  3. Process the turn through the hardened local-media allowlist path.

Expected

  • The saved inbound image remains readable and the turn proceeds to media understanding/model handling.

Actual

  • The saved path is rejected as outside allowed roots, which can fail the turn before the model sees the image.

Evidence

  • Failing test/log before + passing after
  • Trace/log snippets
  • Screenshot/recording
  • Perf numbers (if relevant)

Human Verification (required)

  • Verified scenarios: ran pnpm test -- src/media/local-roots.test.ts and pnpm check; confirmed the new regression test passes and the repo check gate is green.
  • Edge cases checked: verified the merged roots still keep the state-dir workspace/sandbox roots and only add the managed config-dir media cache.
  • What you did not verify: I did not run a live Telegram bot roundtrip against a real upgraded account in this environment.

Review Conversations

  • I replied to or resolved every bot review conversation I addressed in this PR.
  • I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

  • Backward compatible? (Yes/No) Yes
  • Config/env changes? (Yes/No) No
  • Migration needed? (Yes/No) No
  • If yes, exact upgrade steps:

Risks and Mitigations

  • Risk: trusting the wrong extra root could widen local reads more than intended.
    • Mitigation: the added root is limited to the managed config-dir media cache only; workspace and sandbox trust still stays anchored to the active state dir.

Made with Cursor

Changed files

  • src/media/local-roots.test.ts (modified, +22/-0)
  • src/media/local-roots.ts (modified, +19/-9)

PR #59971: fix(telegram): keep inbound images readable on upgraded installs

Description (problem / solution / changelog)

Summary

  • Problem: Telegram image attachments can fail on upgraded installs where the active state dir still resolves to the legacy ~/.clawdbot tree while inbound media is saved under ~/.openclaw/media.
  • Why it matters: the hardened local-media allowlist rejects the saved image path, so Telegram photo-only turns can fail before the image reaches media understanding or the model.
  • What changed: src/media/local-roots.ts now trusts the managed config-dir media cache in addition to the active state-dir roots, and src/media/local-roots.test.ts adds a regression test for the legacy/new dir split.
  • What did NOT change (scope boundary): this does not widen local media reads beyond OpenClaw-managed directories and does not change Telegram download behavior itself.

Change Type (select all)

  • Bug fix
  • Feature
  • Refactor required for the fix
  • Docs
  • Security hardening
  • Chore/infra

Scope (select all touched areas)

  • Gateway / orchestration
  • Skills / tool execution
  • Auth / tokens
  • Memory / storage
  • Integrations
  • API / contracts
  • UI / DX
  • CI/CD / infra

Linked Issue/PR

  • Closes #59956
  • Related #59956
  • This PR fixes a bug or regression

Root Cause / Regression History (if applicable)

  • Root cause: inbound media writes already target resolveConfigDir()/media, but the local-media allowlist only trusted roots derived from resolveStateDir(). On upgraded installs those can diverge (~/.clawdbot vs ~/.openclaw), so the just-saved Telegram image path was treated as outside the allowed roots.
  • Missing detection / guardrail: there was no regression coverage for the legacy-state/new-config split in media local-root resolution.
  • Prior context (git blame, prior PR, issue, or refactor if known): the user report in #59956 points at the 2026.4.x hardening changes; this fix stays in the hardened path and narrows the compatibility gap instead of weakening the policy.
  • Why this regressed now: stricter local-media path validation made the state-dir/config-dir mismatch observable for Telegram inbound images.
  • If unknown, what was ruled out: ruled out Telegram getFile/download failures because the failing path is after media save and before media understanding/model handoff.

Regression Test Plan (if applicable)

  • Coverage level that should have caught this:
    • Unit test
    • Seam / integration test
    • End-to-end test
    • Existing coverage already sufficient
  • Target test or file: src/media/local-roots.test.ts
  • Scenario the test should lock in: a legacy state dir and new config dir can diverge, but inbound media must still be readable from the managed config-dir media cache.
  • Why this is the smallest reliable guardrail: the bug is in local-root resolution, so the direct root-merging test covers the exact regression without adding a heavier Telegram harness dependency.
  • Existing test that already covers this (if any): None.
  • If no new test is added, why not: N/A

User-visible / Behavior Changes

  • Telegram image/photo turns on upgraded installs with legacy state-dir layouts can reach media understanding/model processing again instead of failing early.

Diagram (if applicable)

Before:
Telegram photo -> save under ~/.openclaw/media -> allowlist trusts ~/.clawdbot roots only -> attachment read blocked -> request fails

After:
Telegram photo -> save under ~/.openclaw/media -> allowlist trusts managed state-dir + config-dir media roots -> attachment read succeeds -> request proceeds

Security Impact (required)

  • New permissions/capabilities? (Yes/No) No
  • Secrets/tokens handling changed? (Yes/No) No
  • New/changed network calls? (Yes/No) No
  • Command/tool execution surface changed? (Yes/No) No
  • Data access scope changed? (Yes/No) No
  • If any Yes, explain risk + mitigation:

Repro + Verification

Environment

  • OS: macOS
  • Runtime/container: Node 24 / pnpm workspace
  • Model/provider: N/A for the regression test
  • Integration/channel (if any): Telegram
  • Relevant config (redacted): upgraded install with legacy state dir still resolving to ~/.clawdbot

Steps

  1. Start from an upgraded install where resolveStateDir() still resolves to the legacy state tree.
  2. Receive a Telegram photo so inbound media is saved under the managed config-dir media cache.
  3. Process the turn through the hardened local-media allowlist path.

Expected

  • The saved inbound image remains readable and the turn proceeds to media understanding/model handling.

Actual

  • The saved path is rejected as outside allowed roots, which can fail the turn before the model sees the image.

Evidence

  • Failing test/log before + passing after
  • Trace/log snippets
  • Screenshot/recording
  • Perf numbers (if relevant)

Human Verification (required)

  • Verified scenarios: ran pnpm test -- src/media/local-roots.test.ts and pnpm check; confirmed the regression test passes and the repo check gate is green after addressing the prior review note on the test.
  • Edge cases checked: verified the merged roots still keep the state-dir workspace/sandbox roots and only add the managed config-dir media cache.
  • What you did not verify: I did not run a live Telegram bot roundtrip against a real upgraded account in this environment.

Review Conversations

  • I replied to or resolved every bot review conversation I addressed in this PR.
  • I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

  • Backward compatible? (Yes/No) Yes
  • Config/env changes? (Yes/No) No
  • Migration needed? (Yes/No) No
  • If yes, exact upgrade steps:

Risks and Mitigations

  • Risk: trusting the wrong extra root could widen local reads more than intended.
    • Mitigation: the added root is limited to the managed config-dir media cache only; workspace and sandbox trust still stays anchored to the active state dir.

Made with Cursor

Changed files

  • CHANGELOG.md (modified, +1/-0)
  • src/media/local-roots.test.ts (modified, +17/-0)
  • src/media/local-roots.ts (modified, +19/-9)
RAW_BUFFERClick to expand / collapse

Description

Sending any image via Telegram results in a generic error response: "Something went wrong while processing your request. Please try again."

This began after updating from 2026.3.31 → 2026.4.2. Images were working prior to the update.

Reproduction Steps

  1. Have a working Telegram channel configured with OpenClaw
  2. Update to 2026.4.2 (openclaw update)
  3. Send any image/photo via Telegram DM to the bot
  4. Receive: Something went wrong while processing your request. Please try again.

Expected Behavior

Image is passed to the configured vision-capable model (e.g. anthropic/claude-sonnet-4-6) and processed normally.

Actual Behavior

Error is returned immediately. No image-related entries appear in the gateway log — the image does not reach the model at all, suggesting the failure is in the media handling pipeline before the model call.

Environment

  • OpenClaw version: 2026.4.2
  • Previous version (working): 2026.3.31
  • OS: macOS 26.3.2 (x86_64)
  • Channel: Telegram
  • Primary model: anthropic/claude-sonnet-4-6
  • Node: v24.14.0

Notes

  • Tested with multiple images (screenshots, photos) — all fail consistently
  • Audio transcription config is present but no explicit vision/image model configured — relying on native model vision support
  • The 2026.4.x release introduced security hardening; suspect media handling pipeline may have been affected
  • No image-related errors appear in gateway log — error occurs before logging

Workaround

None currently known. Rolling back to 2026.3.31 would likely restore functionality.

extent analysis

TL;DR

Reverting to OpenClaw version 2026.3.31 is likely to resolve the issue with sending images via Telegram.

Guidance

  • Review the release notes for OpenClaw version 2026.4.2 to understand the security hardening changes and their potential impact on media handling.
  • Verify that the issue persists across different types of images and Telegram configurations to rule out any specific image or configuration-related problems.
  • Consider testing the image sending functionality with a different model or channel to isolate if the issue is specific to the anthropic/claude-sonnet-4-6 model or Telegram channel.
  • Check for any updates or patches for OpenClaw version 2026.4.2 that may address the media handling pipeline issue.

Example

No specific code snippet is applicable in this case, as the issue seems related to a version change and its impact on the media handling pipeline.

Notes

The lack of image-related errors in the gateway log suggests that the issue occurs before the image is processed by the model, pointing towards a problem in the media handling pipeline introduced in the 2026.4.x release.

Recommendation

Apply the workaround of rolling back to OpenClaw version 2026.3.31, as it is known to work and no other workaround is currently available. This should restore the functionality of sending images via Telegram until a fix for version 2026.4.2 is released.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

openclaw - ✅(Solved) Fix Telegram: image/photo attachments fail with "Something went wrong" after 2026.4.x update [2 pull requests, 4 comments, 3 participants]