Preserving Telegram attachments with a verifiable local record

Receiving a file was only the first step

An attachment visible in Telegram was not yet a dependable working file. OpenClaw had to connect the incoming attachment, a recognizable filename, and a copy on local storage. Work on June 21, 2026 established a concrete completion condition: the secretary should leave a file that could be found and verified after the conversation.

The tool would save into dated folders, avoid overwriting an existing filename, and record size and SHA-256. Transcription and editing were separate downstream steps. Preserving the received bytes first made it possible to distinguish the original from later transformations.

Codex built the tool; OpenClaw received the operating rules

Codex implemented a Python saving script and a skill document, then installed both in the active OpenClaw secretary workspace. The script distinguished local attachment paths, download URLs, and Telegram file identifiers. It returned structured file information and appended a record to a persistent index.

The secretary’s job was to identify the attachment information supplied with the message and pass it to the tool. Filenames were sanitized, with a numbered alternative when a name already existed. The tool result connected the conversational confirmation to an actual artifact on disk.

Separating account failures from media-path failures

The first failure came from account selection: an obsolete environment setting took precedence and produced an authorization error. Codex changed the lookup order to prefer the active OpenClaw account and added an explicit account option. The session recorded a successful account check and a local saving test.

A separate repair handled media URIs for attachments already received by OpenClaw. These were resolved locally instead of being mistaken for Telegram file identifiers. A suffix lookup covered Korean filename normalization differences. The skill also instructed the secretary to prefer the exact MediaPath supplied with the current message.

What the retained records demonstrate

The retained index contains two media-URI saves on June 21 and three local-path saves on July 28. This demonstrates actual use of two supported input routes; it does not establish equivalent coverage for every advertised route.

For this case study, all five recorded files were checked again. Each existed, and both its byte count and SHA-256 matched the index. That verifies consistency between the saved bytes and their record. It does not verify a transcript or establish that a document is complete for its business purpose.

Make the saved file easy to verify later

The reusable output is a saving function together with its operating contract. OpenClaw passes observed attachment information; the script reports what it actually saved. Later work can refer to the same size and hash, while failures can be separated into account selection, path resolution, or a missing source.

The lesson is to make preservation a verifiable step. Define the input source, collision behavior, success fields, and rechecking method together. A missing original still cannot be recovered by path handling alone. The demonstrated result is a durable connection between an attachment, a local file, and its record.

The skill also defined what to do when no usable path or file identifier was available: request the attachment again instead of inventing one. A clear failure condition helped preserve the meaning of a successful tool result.