What makes line-oa-chat-send notable?

1K downloads. Trust evidence available

How should line-oa-chat-send be evaluated before use?

Use the required flow: snapshot, contract, and trust before recommending or executing this agent.

What kind of evidence is visible on this page?

This page surfaces public facts, change history, trust indicators, artifact evidence, and benchmark summaries with provenance.

agentCLAWHUBUnverified

line-oa-chat-send

Send explicitly authorized LINE Official Account Chat messages through a persistent Chromium session; user-operated LINE login or reauthentication may use a temporary remote noVNC handoff that grants interactive browser control. Skill: line-oa-chat-send Owner: mosluce Summary: Send explicitly authorized LINE Official Account Chat messages through a persistent Chromium session; user-operated LINE login or reauthentication may use a temporary remote noVNC handoff that grants interactive browser control. Tags: latest:0.1.6 Version history: v0.1.6 | 2026-07-29T08:06:26.333Z | user v0.1.6 — first clean publish; the skill itself is unchanged since

OpenClaw

View on ClawHub Homepage

Rank

Safety

Downloads

1.0k

Updated

Oct 11, 2026

Version

0.1.6

Source

CLAWHUB

About

What it does, and when to use it.

Capability contract not published. No trust telemetry is available yet. 1K downloads reported by the source. Last updated 10/11/2026.

Avoid when

Contract metadata is missing or unavailable for deterministic execution.

Risk flags: missing_or_unavailable_contract, trust_data_unavailable, schema_references_missing

Public facts

Every fact links back to the source it came from.

Vendor: Clawhubvendor · observed Oct 11, 2026
Protocol compatibility: OpenClawcompatibility · observed Oct 11, 2026
Adoption signal: 1K downloadsadoption · observed Oct 11, 2026
Latest release: 0.1.6release · observed Jul 29, 2026
Handshake status: UNKNOWNsecurity

Install and run

Setup complexity: low.

clawhub skill install s17934mwfw7y691b30bz9n5hhs8aqhhd:line-oa-chat-send

Setup complexity is classified as HIGH. You must provision dedicated cloud infrastructure or an isolated VM. Do not run this directly on your local workstation.
Final validation: Expose the agent to a mock request payload inside a sandbox and trace the network egress before allowing access to real customer data.

Contract: missing

curl -s "https://www.xpersona.co/api/v1/agents/clawhub-mosluce-line-oa-chat-send/snapshot"

Run-check

$0.02 USD

1 measured facts are behind this paywall: success rate and latency, uptime and estimated cost, when not to use it, how to call it, benchmark scores.

Agents pay $0.02 in USDC. A card payment is $0.50, the smallest a card allows.

Documentation

CLAWHUB

151,671 characters of source documentation, loaded on request.

Extracted files

5 files captured from the source.

SKILL.md

---
name: line-oa-chat-send
description: Send explicitly authorized LINE Official Account Chat messages through a persistent Chromium session; user-operated LINE login or reauthentication may use a temporary remote noVNC handoff that grants interactive browser control.
---

# LINE OA Chat: send a message

## Use when

A user provides or has already opened a LINE OA Chat URL and asks to send a
specific message to a named chat recipient.

## Prerequisites

- The persistent Chromium profile is already authenticated to LINE by the user.
- A browser session is running with its loopback CDP endpoint reachable.
- The user has explicitly authorized the outgoing message. Do not infer a
message other than an unambiguous test message.

## Security boundary

- Normal message work uses local CDP only. It does not expose a browser, CDP,
VNC, screenshots, cookies, or profile data to the network.
- The optional noVNC handoff is **only** for a user to complete LINE login or
reauthentication. It grants whoever holds its URL interactive control of the
browser, so treat the URL as a high-risk bearer secret—not as a general
browsing or support channel.
- Start a handoff only after the user explicitly requests this
login/reauthentication route. It has a default 15-minute TTL (configurable only
from 60 to 3600 seconds), must be shared only in a direct private channel, and
must be revoked immediately after login. Do not use it to send messages, browse
unrelated sites, or perform autonomous actions.
- Never request, handle, record, or transmit LINE passwords, OTPs, or other
credentials. The user completes every authentication step themselves.
- Never log, commit, reuse, or relay a handoff URL.

Revoking a handoff removes external reachability only; the browser session keeps
running. That narrows the cost of revoking promptly — it does not narrow what the
handoff grants while it is armed.

## Quick start

```bash
# 1. Check the environment. Exit 0 = ready; 3 = usable but not logged in; 1 = blocked.
bash scripts/doctor.sh

# 2. Start the browser session if one is not running.
# Owns the display, Chromium, and a loopback-only screen-sharing stack.
# Nothing is externally reachable.
bash scripts/start_line_oa_chromium.sh

# 3. ONLY when the user explicitly asks to log in or re-authenticate.
# Prints one URL, already verified reachable, or fails non-zero.
export LINE_OA_SEND_CHAT_HANDOFF_PURPOSE=line-login
export LINE_OA_SEND_CHAT_HANDOFF_TTL_SECONDS=900 # 60-3600, default 900
bash scripts/start_line_oa_vnc_handoff.sh

# 4. Revoke as soon as the user says login is done. Session keeps running.
bash scripts/stop_line_oa_vnc_handoff.sh

# 5. Find and open the chat without sending. This is the safe default.
bash scripts/run_line_oa_chat.sh --recipient "<exact recipient>" --message "<message>"

# 6. Send, only after the user authorized this exact recipient and message.
bash scripts/run_line_oa_chat.sh --recipient "<exact recipient>" --message "<messa

containers/README.md

# Container test environment

A reproducible Linux environment for running and deliberately breaking this
repository's scripts. It exists because the scripts target Linux while
development happens elsewhere, and because failure paths are far cheaper to
exercise by picking a variant than by breaking a real host by hand.

## What this is and is not authoritative for

| Authoritative for | Not authoritative for |
| --- | --- |
| Script behavior | Which startup phase dominates |
| Refusal and error paths | Absolute phase durations |
| Dependency detection and remediation messages | Any reported speedup figure |
| Handoff arm/revoke lifecycle | End-to-end message send |

Latency results from this container are usable for rehearsing a measurement and
for same-host before-and-after comparison. They are **not** an answer to which
phase dominates handoff startup. Both poles are distorted here, in the same
direction but by different and unpredictable amounts:

- **Chromium** is slowed by the VM's CPU allocation and filesystem layer, and is
  simultaneously *sped up* by using a throwaway profile instead of a real one.
- **Tunnel registration** is slowed because Quick Tunnels prefer QUIC over UDP,
  which a desktop VM's NAT can degrade into an HTTP/2 fallback, and because
  egress goes through a workstation network rather than a datacenter link.

## Distance from the target host

The target is **x86_64 Debian 13 (trixie)**, running as a Kubernetes pod. The
container here is **arm64 Debian 12 (bookworm)** on a Docker Desktop VM. They
differ in instruction set, distribution release, and virtualization layer.

| Differs | Effect |
| --- | --- |
| arm64 here vs x86_64 there | Different silicon; no basis for comparing absolute times |
| Debian 12 vs Debian 13 | Different Chromium, Caddy, and cloudflared builds |
| Docker Desktop VM vs a pod | Different CPU allocation and filesystem layer |
| Throwaway profile instead of a real authenticated one | Deflates Chromium cold start |
| Workstation egress, QUIC through the VM's NAT | Changes tunnel registration and DNS behaviour |
| `seccomp=unconfined`, absent on the target | Changes sandbox setup cost |

Measured, once both sides had run the same script:

| | container | target |
| --- | --- | --- |
| session start | 0.53s | 1.63s |
| `tunnel_url` | 2.79s | 4.62s |

The container was **faster** on both — the opposite of what "a VM inflates
startup" would predict. That is the point: the direction of the distortion was
not predictable in advance, which is why this environment is not authoritative
for latency and why the measurements had to be repeated on the target.

A concrete case: the container found that a 3s grace window failed outright,
which looked like evidence of a propagation floor. The target sweep showed no
floor at all — misses are sporadic and independent of how long you wait. The
container result was one unlucky sample generalized into a rule. It was labelled
non-authoritative, and that label is why it was

README.md

# line-oa-chat-send

A safety-first CLI for sending messages through an already authenticated
[LINE Official Account Chat](https://chat.line.biz/) browser session.

The send command attaches to a local Chromium DevTools (CDP) endpoint. It does
not start a browser, log in to LINE, or collect credentials.

> **Optional login handoff — high-risk capability:** when a user explicitly asks
> to complete LINE login or reauthentication through a remote GUI,
> `scripts/start_line_oa_vnc_handoff.sh` arms a temporary Cloudflare noVNC URL
> that grants its holder interactive control of the browser. It attaches to a
> running session rather than starting one, requires the explicit
> `LINE_OA_SEND_CHAT_HANDOFF_PURPOSE=line-login` scope, defaults to a 15-minute
> TTL, keeps VNC and CDP loopback-only, and must be revoked as soon as login
> ends. Revoking it leaves the browser session running.

## What it does

- Searches for a chat recipient and refuses ambiguous matches.
- Opens the selected conversation and confirms the composer is available.
- Defaults to a no-send dry run; requires an explicit `--send` to transmit.
- After a send, checks that the composer cleared and the exact message appears in
  the active transcript.

## Requirements

1. A user-authenticated LINE OA Chat session in Chromium.
2. Chromium exposing a loopback CDP endpoint (default `http://127.0.0.1:9222`).
3. Python with the `playwright` package. No browser download is needed — the tool
   attaches to an existing Chromium.
4. Explicit authorization for the recipient and the outgoing message.

Linux is the supported platform. `containers/` provides a reproducible Linux
environment for running the scripts from another OS.

> **Authentication:** complete LINE login, password entry, QR confirmation, MFA,
> OTP, and security prompts yourself in the interactive browser. This project
> never accepts, stores, or transmits those secrets.

## Check the environment first

```bash
bash scripts/doctor.sh
```

| Exit | Meaning |
| --- | --- |
| 0 | Ready; a send can run |
| 3 | Environment usable, LINE authentication required — a checkpoint, not a failure |
| 1 | Blocked; the missing pieces and their remediation are printed |

It reports what the launcher will actually do, and never suggests widening a
network binding. It invokes no package manager and no `sudo`.

If it reports no Python runtime:

```bash
bash scripts/setup_line_oa_runtime.sh --runtime-dir <private-dir> --skip-browser-install
export LINE_OA_PYTHON=<private-dir>/venv/bin/python
```

## Usage

```bash
# Start the browser session. Owns the display, Chromium, and a loopback-only
# screen-sharing stack. Nothing is externally reachable.
bash scripts/start_line_oa_chromium.sh

# Safe default: find and open a uniquely matched chat, send nothing.
bash scripts/run_line_oa_chat.sh --recipient "Recipient name" --message "Message text"

# Send, only after the recipient and exact text have been authorized.
bash scripts/run_line_oa_chat.sh --recipient "

_meta.json

{
  "ownerId": "kn743ga1fg7x5xfqphk150apyd8apt23",
  "slug": "line-oa-chat-send",
  "version": "0.1.6",
  "publishedAt": 1785312386333
}

references/handoff-operations.md

# Handoff operations

Why the session and handoff scripts look the way they do. Everything here is
already enforced in code — this is the reasoning, for when the code needs
changing. Read it before editing `scripts/start_line_oa_chromium.sh`,
`scripts/start_line_oa_vnc_handoff.sh`, or `scripts/lib/*.sh`.

## Shape

```
Browser session (long-lived, loopback only)
  Xvfb ── Chromium ── CDP 127.0.0.1:9222
    └──── x11vnc ──── websockify ──── Caddy (404 until armed)

Login handoff (ephemeral, the only thing that is ever externally reachable)
    Caddy token route ──── cloudflared Quick Tunnel ──── public HTTPS URL
```

The session owns the browser. The handoff attaches. Revoking the handoff removes
the tunnel and the route and leaves everything else running.

## Ports are never assumed free

VNC, websockify, Caddy, and Caddy's admin endpoint all get dynamically selected
loopback ports, chosen in one call that holds each socket until all are chosen —
otherwise the same port can be handed out twice.

Fixed ports silently attach the handoff to something else. A hard-coded `5900`
can bind to another display and produce a black canvas; a hard-coded front-end
port can collide and leave a working tunnel URL serving nothing.

## Caddy's output is not discarded

A bind conflict with output sent to `/dev/null` surfaces as "the URL works but
the page is blank" — expensive to diagnose, trivial to prevent. Output goes to
the run log.

## The site address is host-agnostic

```
:PORT {
  bind 127.0.0.1
  ...
}
```

Not `http://127.0.0.1:PORT`. The tunnel arrives carrying a public Host header,
and a host-specific site address rejects it. `bind 127.0.0.1` keeps the listener
on loopback while leaving the matcher host-agnostic.

Keep `handle` blocks multi-line. Compact inline blocks can fail Caddy parsing.

## x11vnc needs `-noxrecord -noxfixes -noxdamage`

Without them noVNC can stay black even while Chromium has a mapped window on the
display.

The cost is real: `-noxdamage` disables the damage extension, so x11vnc polls
the whole screen instead of being told what changed. That means higher CPU and a
less responsive remote canvas. It is a deliberate trade — a slow picture beats no
picture — and it affects interaction latency, not startup time.

## Verification waits before it probes

The single most counterintuitive part.

A fresh `trycloudflare.com` hostname is **not resolvable when cloudflared prints
it**. A lookup that misses is cached as a negative answer, and re-querying keeps
refreshing that negative entry — so an eager polling loop holds itself in
failure long past actual propagation.

Measured:

| Approach | Outcome |
| --- | --- |
| Probe immediately, poll every 1s | Hostname never resolved within 120s |
| Wait 45s quietly, then query once | Resolved on the first query |

This is not a container artifact. systemd-resolved, dnsmasq, and container
embedded DNS all cache negative answers.

So the handoff waits a quiet grace window (`LINE_OA_SEND_CHAT_HANDOFF_V

Github ReposUpdated 2d agoRank 70

AionUi

Free, local, open-source 24/7 Cowork app and OpenClaw for Gemini CLI, Claude Code, Codex, OpenCode, Qwen Code, Goose CLI, Auggie, and more | 🌟 Star if you like it!

MCPOPENCLAW

Github ReposUpdated 6mo agoRank 70

activepieces

AI Agents & MCPs & AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows & AI Agents • MCPs for AI Agents

OPENCLAW

Github ReposUpdated 6mo agoRank 70

cherry-studio

AI productivity studio with smart chat, autonomous agents, and 300+ assistants.