Douyin: Send a DM via Chrome

intent

send a text DM to a Douyin user from the user's signed-in Chrome session, then verify the message actually delivered. Douyin will silently render message bubbles even when DMs are banned or blocked, so verification is mandatory before claiming success. use this skill whenever the user asks to send, DM, message, or 发私信 to someone on Douyin / 抖音 / douyin.com, including cases where they only describe the action ("tell @xyz hi", "ping that creator on Douyin"). works for the web client only and only when sender and recipient are mutual followers (相互关注).

inputs

• chrome 144+ with CDP on 127.0.0.1:9222. launch with --remote-debugging-port=9222, or open chrome://inspect/#remote-debugging, click configure…, and follow in-page steps until you see server running at: 127.0.0.1:9222.
• openclaw user browser profile. built-in, no extra config. browser action=start profile=user spawns chrome-devtools-mcp and attaches automatically.
• user logged into douyin.com in that Chrome session.
• sender and recipient must be mutual followers (相互关注). douyin web blocks DMs to non-mutuals. if the target's profile shows only "关注" (follow) instead of "相互关注", the skill cannot proceed.
• sender's DM privilege not banned. if banned, the message bubble still renders locally with a tip "私信功能已被封禁" (DM function banned). the verification step detects this.
• network connectivity to douyin.com and chrome devtools endpoint.

procedure

step 1: attach to Chrome and select tab

browser action=start profile=user
browser action=tabs profile=user

pick an empty tab from the tabs list, or prepare to open a new one. save its targetId and pass it to all subsequent calls to keep the same tab.

input: none (uses existing session) output: targetId of chosen tab

step 2: find the target user via search

navigate the chosen tab to a user search:

browser action=navigate profile=user targetId=<id>
  url=https://www.douyin.com/search/<URL-encoded query>?type=user

take a snapshot with refs="aria" and pick the result whose card shows "相互关注" and whose 抖音号 / bio matches what the user described. if multiple plausible results exist, ask the user to confirm before proceeding.

click that result link by ref. it opens the profile in a new tab. snapshot or call browser action=tabs again to find the new tab's targetId (url pattern: https://www.douyin.com/user/MS4wLj…). switch to that tab for the rest of the flow.

input: target user name or descriptor from user output: profile tab targetId, verified as "相互关注"

step 3: open the DM panel from profile page

critical: two 私信 controls exist on the profile page.

• header 私信 (top-right, around x≈1542) opens the global DM panel with no conversation selected.
• profile-page 私信 button (next to "相互关注", around x≈1562 y≈158) opens the panel with the correct conversation already selected.

always click the profile-page button. find it via DOM filter, not by ref (ref tree sometimes returns the wrong element):

browser action=act profile=user targetId=<profile-tab>
  request={"kind":"evaluate","fn":"() => { const btns=[...document.querySelectorAll('button')].filter(b=>(b.innerText||'').trim()==='私信' && b.offsetParent!==null); for (const b of btns){ const r=b.getBoundingClientRect(); if (r.width>30 && r.width<200 && r.height>20 && r.height<60 && r.x>200){ b.click(); return JSON.stringify({clicked:true,x:Math.round(r.x),y:Math.round(r.y)}); } } return JSON.stringify({found:btns.length}); }"}

wait for the panel to render:

browser action=act profile=user targetId=<id>
  request={"kind":"wait","timeMs":1500}

verify the correct conversation is selected by reading .RightPanelHeadertitle:

browser action=act profile=user targetId=<id>
  request={"kind":"evaluate","fn":"() => { const h=document.querySelector('.RightPanelHeadertitle'); return h?h.innerText:null; }"}

the result must equal the target user's display name. if null or wrong, the DM panel didn't open or the wrong row got selected. retry the click.

input: profile tab targetId output: DM panel open with correct conversation selected, verified via .RightPanelHeadertitle

step 4: type the message

the message editor is a [contenteditable="true"] with placeholder "发送消息". standard act:type rejects coords-only focus on existing-session driver, so write text via execCommand:

browser action=act profile=user targetId=<id>
  request={"kind":"evaluate","fn":"() => { const ed=[...document.querySelectorAll('[contenteditable=\"true\"]')].find(e=>{const r=e.getBoundingClientRect();return r.width>100 && r.height>20;}); if(!ed) return 'no-editor'; ed.focus(); const sel=window.getSelection(); const range=document.createRange(); range.selectNodeContents(ed); range.collapse(false); sel.removeAllRanges(); sel.addRange(range); document.execCommand('insertText',false,'<MESSAGE TEXT>'); return ed.innerText; }"}

replace <MESSAGE TEXT> with the user's message. escape single quotes (' → \\'). the returned innerText should match the message (trailing zero-width char is fine).

input: message text from user, tab targetId output: message text visible in editor's innerText

step 5: send the message

browser action=act profile=user targetId=<id>
  request={"kind":"press","key":"Enter"}

input: tab targetId output: Enter key pressed

step 6: verify delivery (mandatory)

inspect the DOM for both signals:

browser action=act profile=user targetId=<id>
  request={"kind":"evaluate","fn":"() => { const ed=[...document.querySelectorAll('[contenteditable=\"true\"]')].find(e=>{const r=e.getBoundingClientRect();return r.width>100 && r.height>20;}); const editorText=ed?ed.innerText.trim():null; const list=document.querySelector('.messageMessageListwrapper'); const listText=list?list.innerText.slice(0,400):''; const banned=/私信功能已被封禁|对方拒收|不是Ta的好友|无法发送/.test(listText); return JSON.stringify({editorEmpty:!editorText||editorText==='\u200b'||editorText==='', listText, banned}); }"}

input: tab targetId output: JSON with editorEmpty, listText, banned flags

decision points

if search returns multiple "相互关注" matches: ask the user to disambiguate by 抖音号 or bio before clicking any result.

if no 私信 button appears on profile, only "关注" or single "相互关注": sender and recipient are not mutuals. tell the user douyin web doesn't allow DMs to non-mutuals and they must follow each other first.

if .RightPanelHeadertitle is null or doesn't match target name after clicking: the DM panel didn't open or the wrong conversation row got selected. retry step 3's click, then re-verify the title.

if editorEmpty is true and banned is false: message delivered successfully. confirm to user and close the interaction.

if editorEmpty is true and banned is true: message sent locally but douyin blocked it. tell the user the bubble appears on their screen but the recipient won't receive it. quote the exact ban/block reason douyin shows and recommend they check their douyin notifications for details.

if editorEmpty is false (editor still has text): send didn't fire (Enter consumed by IME, no focus, or keyboard event failed). retry steps 4 and 5.

if browser action=screenshot fails with ENOENT … openclaw-chrome-mcp-…: known existing-session driver quirk. skip screenshots and rely on DOM inspection (evaluate requests) for verification.

if header 私信 button was clicked instead of profile button: the global DM panel opened or closed without selecting the right chat. always re-check .RightPanelHeadertitle matches the target name.

if DOM evaluate accidentally clicks page-wide containers: constrain queries with getBoundingClientRect size filters (e.g. width<400 && height<100) to avoid false positives.

if act:type errors with "type requires ref or selector": existing-session driver rejects coords-only focus. use the execCommand('insertText', …) evaluate pattern from step 4.

if chrome MCP attach times out (chrome MCP existing-session attach … timed out): verify curl -s http://127.0.0.1:9222/json/version returns JSON. if 404, chrome's devtools endpoint isn't running. relaunch chrome with --remote-debugging-port=9222.

if network timeout or douyin.com unreachable: wait 3 seconds and retry the navigate step. if persistent, tell the user to check their internet and douyin.com status.

output contract

successful skill execution produces:

• message text visible in the message list under the recipient's name in the DM panel
• editor field cleared (editorEmpty = true)
• no ban/block warning in the message list (banned = false)
• skill returns a structured confirmation to the user with the exact message text and recipient name

failed execution (due to ban, block, or send failure) produces:

• skill returns the exact warning message from douyin's DOM (e.g. "私信功能已被封禁")
• editor state and message list contents as JSON, for debugging
• clear guidance on what the user must do next (check notifications, verify mutual follow, etc.)

outcome signal

the user knows the skill worked when:

• the message appears in the DM conversation thread under the target user's name
• the message editor clears (becomes empty)
• the skill explicitly says "message delivered to [user name]" or quotes the exact message text and recipient

the user knows the skill failed when:

• the message editor still has text (send didn't fire)
• the skill reports douyin's ban/block warning and quotes the exact tip (e.g. "私信功能已被封禁")
• the skill says "not mutuals" because the profile shows only "关注" instead of "相互关注"
• the skill says "verify failed: please retry send" due to DOM inspection errors

never claim "message sent" based only on a bubble appearing locally. always run step 6 and report the live DOM state.