⚠️ 🚨 CRITICAL BUTTON STRUCTURE WARNING 🚨
The buttons array from the script is a 2D array where each inner array = one row.
ALWAYS pass it directly to the message tool without modification.

• - In OpenClaw context: use response['buttons'] directly
• In Python scripts: use payload['buttons'] from INLINECODE3

❌ NEVER flatten, restructure, re-group, or stringify rows.

Zero-Footgun Protocol

When sending any browser menu, follow the correct workflow for your context:

If in OpenClaw (using exec + message tools):

1. 1. Run browser_dispatcher.py via exec tool
2. Use response['messageToolCall'] as the complete payload for the message tool
3. Don't touch the buttons — use them exactly as returned inside that payload
4. If send succeeds and the response includes postSend, then update liveMessageId and optionally delete the previous menu

If in standalone Python script:

1. 1. Generate plan via run_browser_action.py or import functions
2. Run build_message_payload(plan) and require INLINECODE11
3. Use payload['message'] and payload['buttons'] from the validated result

Common mistakes to avoid:

• - ❌ Don't rewrite buttons manually
• ❌ Don't flatten buttons into one row
• ❌ Don't pass buttons as a JSON string

Telegram File Browser

Build Telegram file-browsing flows around a single live menu plus optional side messages for previews, paths, and downloads.

Invocation

When the user explicitly invokes telegram-file-browser or asks to use this skill:

1. 1. Open an interactive browser immediately in the same turn.
2. Default the root to ~/.openclaw/workspace unless the user gave a path.
3. Do not reply with a conversational clarification like “你想让我做什么？” when the user already asked to browse.
4. Ask a follow-up only when the target path or safety boundary is genuinely ambiguous.
5. If the input is config, open the configuration flow instead of the browser tree.

Do not stop at describing the skill when you already have enough information to launch the UI.

Runtime Contexts

This skill can be used in two different contexts. Choose the one that matches your environment.

Context 1: OpenClaw Tool Calls (Most Common)

When you're running inside OpenClaw and using exec + message tools (like right now), use browser_dispatcher.py via exec, then call the message tool with the exact JSON from the script.

⚠️ The script already validates and returns the correct payload — use it directly, don't rewrite anything.

Step 1: Run the script via exec tool

CODEBLOCK0

Step 2: Call message tool with the script's output

CODEBLOCK1

Complete example:

CODEBLOCK2

Callback handling:

CODEBLOCK3

Important for current Telegram/OpenClaw routing:

If a button click arrives as a plain inbound text message like tfb_root_v12_w8 instead of a native callback event, treat that text as the callback_data and run the exact same callback flow above. Do not ignore it just because it came in as a message.

Recommended detection rule:

• - if inbound text matches INLINECODE23
• treat it as a telegram-file-browser callback
• run browser_dispatcher.py handle-callback <that_text> immediately
• do not ask the user what they mean

Context 2: Standalone Python Script

When you're writing a standalone Python script (not inside OpenClaw), use the import-based approach with build_message_payload.

CODEBLOCK4

Why build_message_payload is required in Python scripts:

• - Validates button structure (2D array, one row per item)
• Returns the exact payload to send
• Prevents common mistakes like flattening buttons

Why it's NOT needed in OpenClaw context:

• - browser_dispatcher.py already returns a validated payload
• Just use the JSON values directly

⚠️ For OpenClaw tool calls: Just use browser_dispatcher.py — see Context 1 above.

The examples below are for standalone Python scripts only.

Tool Plan Contract

In OpenClaw context (most common): Use browser_dispatcher.py — it already validates and returns the correct payload. Just use the JSON values directly.

In standalone Python scripts: Use run_browser_action.py + build_message_payload(plan) as the guardrail.

Supported toolAction values:

Plans that send buttons should also include viewType (for example directory or file-actions) so the validator can enforce row-shape rules.

• - INLINECODE36
• INLINECODE37
• INLINECODE38
• INLINECODE39

Map them to OpenClaw message actions like this:

• - INLINECODE40

    message(action='send', message=response['message'], buttons=response['buttons'])
    

    payload = wrapped["payload"]
    message(action=payload["action"], message=payload["message"], buttons=payload["buttons"])
    

⚠️ Common mistakes to avoid:
CODEBLOCK7

• - INLINECODE46

• - INLINECODE49

• - INLINECODE56

Important runtime note:

• - With the current OpenClaw message tool, Telegram inline buttons are reliably attached on send, not on edit.
• Therefore navigation should be implemented as send a fresh menu, then optionally delete the previous one.
• Treat edit-message mode as replace the prior menu with minimal chat noise, not as a literal button-preserving in-place edit.

Display Modes

Persist display mode in config.json.

edit-message

• - keep one logical live browser menu
• because current OpenClaw tooling does not reliably preserve Telegram buttons on edit, implement this as:

• - best for low-noise chat history

new-message

• - navigation sends a fresh browser menu
• old menus remain in history unless you intentionally delete them
• update liveMessageId to the newly sent menu after success
• previews, path replies, and downloads still reply to the current live menu

Core Interaction Rules

Keep callback payloads short

Never place full file paths in callback_data.

Use opaque ids and store the real mapping in state.

Split navigation from content

Use the menu for navigation only.

Use separate messages for:

• - file previews
• copyable path output
• file downloads
• error notices that should not replace the current menu

File click behavior

When a user clicks a file from a directory listing:

1. 1. Open a file action menu.
2. Do not immediately dump file contents.
3. Offer at least 👁 预览, 📋 路径, ⬇️ 下载, ⬅️ 返回, ❌ 关闭.
4. Prefer one button per row here as well unless a later UX change explicitly says otherwise.

Pagination

Keep pagination inside the same state machine.

Required behavior:

• - page buttons stay versioned like other callbacks
• page changes rebuild the current directory view
• pagination preserves root boundary and current path
• item ids remain resolvable after changing pages

State Requirements

Persist at least:

• - INLINECODE72
• INLINECODE73
• INLINECODE74
• INLINECODE75
• INLINECODE76
• INLINECODE77
• the current view's page metadata

Recommended shape:

CODEBLOCK8

Callback Safety

Protect against replayed and stale callbacks.

Required behavior:

• - include menu version in interactive callbacks
• reject callbacks whose version does not match current state
• debounce duplicate callbacks received in a short window
• prefer silent noop over noisy execution for stale callbacks

Failure Handling

Missing or stale target

If the resolved file or directory no longer exists:

• - keep the browser alive
• send a short failure message or rebuild the nearest valid view
• preserve a way back

Callback execution loop

When Telegram delivers a button click as a callback message such as callback_data: tfb_root_v2_w13, do this immediately:

1. 1. run INLINECODE80
2. inspect the returned tool plan
3. if toolAction == "send", run it through send_plan.py / build_message_payload(plan) first
4. execute the validated payload with the OpenClaw message tool
5. if a fresh menu was sent successfully, write the returned messageId back into state as INLINECODE86
6. if the plan requests previous-menu cleanup, delete the previous menu only after the new menu send succeeds

Do not answer a callback message with a normal conversational reply when the callback belongs to the file browser.
Do not ask a follow-up unless the callback cannot be resolved safely.
Prefer silent noop over chatty recovery for stale callbacks.

Message edit failure

If an edit fails because the menu no longer exists or cannot be edited:

• - send a fresh menu
• update INLINECODE88
• preserve current path and stack when possible

Oversized or invalid callbacks

If Telegram rejects callback payloads:

• - shorten callback ids
• move real state into local storage
• do not encode raw paths in buttons

Bundled Scripts

• - scripts/build_view.py — list a directory, sort entries, paginate, and emit view JSON
• INLINECODE90 — initialize/load/save state and manage current path, back stack, menu version, and live message id
• INLINECODE91 — generate safe file previews
• INLINECODE92 — build Telegram button matrices for directory and file-action views
• INLINECODE93 — resolve callback payloads into browser actions
• INLINECODE94 — orchestrate open-root, open-dir, file actions, back, paging, and live-message state updates
• INLINECODE95 — load and persist display config
• INLINECODE96 — convert browser actions into concrete tool plans for messaging and file delivery
• INLINECODE97 — validate send plans and build the only approved message(action="send", ...) payload
• INLINECODE99 — CLI validator for plan JSON before sending
• INLINECODE100 — regression test for root/page/dir/file-action flows and flattened-button rejection
• scripts/browser_dispatcher.py — ⭐ RECOMMENDED one-click wrapper: generates plan, validates, returns exact payload. Use this instead of hand-rolling the flow.

Runtime artifacts

Treat state/ as runtime-only scratch data. Do not commit it. Keep it ignored in git.

Pre-send Checklist

Before sending or replacing a browser menu, verify all of the following:

In OpenClaw context (using exec + message tools):

• - ✅ You used browser_dispatcher.py to get the plan
• ✅ You passed response['buttons'] directly to the message tool — no manual rewriting
• ✅ buttons is a real 2D array (each inner array = one row)

In standalone Python scripts:

• - ✅ You used build_message_payload(plan) to validate
• ✅ You used payload['buttons'] from the validated result

General rules (always):

• - ⚠️ Never rewrite buttons yourself — use the script's output directly
• ⚠️ Never flatten buttons into one row — keep 2D structure
• ✅ Each directory/file item stays on its own row
• ✅ Callback payloads are short opaque ids, not raw paths
• ✅ replyTo is forwarded when the tool plan includes it
• ✅ After a successful send, liveMessageId is updated
• ✅ When replacing a live menu, send first and delete old menu only after send succeeds

Hard rule

Treat any manual rewrite of plan["buttons"] as a bug, not an optimization.

Notes

Read references/interaction-patterns.md when you need concrete UX guidance for:

• - single-message navigation
• file action menus
• pagination behavior
• copyable path behavior
• menu recovery after edit failures