Web interfaces
वेब चैट
स्थिति: macOS/iOS SwiftUI चैट UI सीधे Gateway WebSocket से बात करता है।
यह क्या है
- Gateway के लिए एक नेटिव चैट UI (कोई एम्बेडेड ब्राउज़र और कोई स्थानीय स्थैतिक सर्वर नहीं)।
- अन्य चैनलों जैसे ही सत्र और रूटिंग नियमों का उपयोग करता है।
- निर्धारक रूटिंग: उत्तर हमेशा WebChat पर वापस जाते हैं।
त्वरित शुरुआत
- Gateway शुरू करें।
- WebChat UI (macOS/iOS ऐप) या Control UI चैट टैब खोलें।
- सुनिश्चित करें कि एक वैध Gateway प्रमाणीकरण पथ कॉन्फ़िगर है (डिफ़ॉल्ट रूप से shared-secret, loopback पर भी)।
यह कैसे काम करता है (व्यवहार)
- UI Gateway WebSocket से कनेक्ट होता है और
chat.history,chat.send, औरchat.injectका उपयोग करता है। - स्थिरता के लिए
chat.historyसीमित है: Gateway लंबे टेक्स्ट फ़ील्ड काट सकता है, भारी मेटाडेटा छोड़ सकता है, और बहुत बड़ी प्रविष्टियों को[chat.history omitted: message too large]से बदल सकता है। - जब
chat.historyमें कोई दृश्यमान assistant संदेश काट दिया गया हो, तो Control UI एक साइड रीडर खोल सकता है और डिफ़ॉल्ट इतिहास पेलोड बढ़ाए बिनाchat.message.getके ज़रिए मांग पर पूरी डिस्प्ले-सामान्यीकृत प्रविष्टि ला सकता है। - आधुनिक केवल-जोड़ने वाली सत्र फ़ाइलों के लिए
chat.historyसक्रिय ट्रांसक्रिप्ट शाखा का पालन करता है, इसलिए छोड़ी गई rewrite शाखाएँ और प्रतिस्थापित prompt प्रतियाँ WebChat में रेंडर नहीं होतीं। - Compaction प्रविष्टियाँ स्पष्ट संकुचित-इतिहास विभाजक के रूप में रेंडर होती हैं। विभाजक समझाता है कि संकुचित ट्रांसक्रिप्ट checkpoint के रूप में संरक्षित है और Sessions checkpoint नियंत्रणों से लिंक करता है, जहाँ ऑपरेटर अपनी अनुमतियाँ होने पर उस संकुचित दृश्य से शाखा बना सकते हैं या restore कर सकते हैं।
- Control UI
chat.historyद्वारा लौटाए गए आधारभूत GatewaysessionIdको याद रखता है और उसे आगे कीchat.sendकॉलों में शामिल करता है, इसलिए reconnect और पेज refresh वही संग्रहीत बातचीत जारी रखते हैं, जब तक कि उपयोगकर्ता कोई सत्र शुरू या reset न करे। - Control UI नई
chat.sendrun id बनाने से पहले उसी सत्र, संदेश, और attachments के लिए डुप्लिकेट in-flight submits को coalesce करता है; Gateway अब भी उसी idempotency key का दोबारा उपयोग करने वाले दोहराए गए अनुरोधों को dedupe करता है। - Workspace startup फ़ाइलें और लंबित
BOOTSTRAP.mdनिर्देश agent system prompt के Project Context के ज़रिए दिए जाते हैं, WebChat उपयोगकर्ता संदेश में कॉपी नहीं किए जाते। Bootstrap truncation केवल संक्षिप्त system-prompt recovery notice जोड़ता है; विस्तृत counts और config knobs diagnostic surfaces पर रहते हैं। chat.historyभी display-normalized है: runtime-only OpenClaw context, inbound envelope wrappers, inline delivery directive tags जैसे[[reply_to_*]]और[[audio_as_voice]], plain-text tool-call XML payloads (जिसमें<tool_call>...</tool_call>,<function_call>...</function_call>,<tool_calls>...</tool_calls>,<function_calls>...</function_calls>, और काटे गए tool-call blocks शामिल हैं), और लीक हुए ASCII/full-width model control tokens दृश्यमान टेक्स्ट से हटा दिए जाते हैं, और ऐसी assistant प्रविष्टियाँ जिनका पूरा दृश्यमान टेक्स्ट केवल exact silent tokenNO_REPLY/no_replyहोता है, छोड़ दी जाती हैं।- Reasoning-flagged reply payloads (
isReasoning: true) WebChat assistant content, transcript replay text, और audio content blocks से बाहर रखे जाते हैं, इसलिए केवल-सोच वाले payloads दृश्यमान assistant संदेशों या चलाए जा सकने वाले audio के रूप में सतह पर नहीं आते। chat.injecttranscript में सीधे एक assistant note जोड़ता है और उसे UI पर broadcast करता है (कोई agent run नहीं)।- रोके गए runs UI में partial assistant output दृश्यमान रख सकते हैं।
- buffered output मौजूद होने पर Gateway रोके गए partial assistant text को transcript history में persist करता है, और उन प्रविष्टियों को abort metadata से चिह्नित करता है।
- History हमेशा Gateway से fetch की जाती है (कोई स्थानीय फ़ाइल watching नहीं)।
- यदि Gateway पहुँच योग्य नहीं है, तो WebChat read-only होता है।
Transcript और delivery model
WebChat में दो अलग-अलग data paths हैं:
- session JSONL फ़ाइल durable model/runtime transcript है। सामान्य agent runs के लिए, embedded OpenClaw runtime अपने session manager के ज़रिए model-visible
user,assistant, औरtoolResultसंदेशों को persist करता है। WebChat उस transcript में मनमाना delivery, status, या helper text नहीं लिखता। - Gateway
ReplyPayloadevents live delivery projection हैं। उन्हें WebChat/channel display, block streaming, directive tags, media embedding, TTS/audio flags, और UI fallback behavior के लिए normalize किया जा सकता है। वे स्वयं canonical session log नहीं हैं। - जिन harnesses को
tools.messageके ज़रिए दृश्यमान replies चाहिए, वे अब भी WebChat को current-run internal source reply sink के रूप में उपयोग करते हैं। उस सक्रिय WebChat run से targetlessmessage.sendउसी चैट में project होता है और session transcript में mirror होता है; WebChat reusable outbound channel नहीं बनता और कभीlastChannelinherit नहीं करता। - WebChat assistant transcript entries केवल तब inject करता है जब Gateway सामान्य embedded agent turn के बाहर displayed message का मालिक हो:
chat.inject, non-agent command replies, aborted partial output, और WebChat-managed media transcript supplements। chat.historystored session transcript पढ़ता है और WebChat display projection लागू करता है। यदि किसी run के दौरान live assistant text दिखाई देता है लेकिन history reload के बाद गायब हो जाता है, तो पहले जाँचें कि raw JSONL में assistant text है या नहीं, फिर किchat.historyprojection ने उसे stripped किया या नहीं, फिर कि Control UI optimistic-tail merge ने local delivery state को persisted snapshot से बदल दिया या नहीं।chat.message.getchat.historyजैसे ही transcript branch और display projection rules का उपयोग करता है, जिसमें active-agent scoping शामिल है, लेकिनmessageIdद्वारा एक transcript entry को target करता है और जब पूरा content अब लौटाया नहीं जा सकता, तो ईमानदार unavailable reason लौटाता है।
सामान्य agent-run final answers durable होने चाहिए क्योंकि embedded runtime assistant message_end लिखता है। delivered final payload को transcript में mirror करने वाले किसी भी fallback को पहले ऐसे assistant turn को duplicate करने से बचना होगा जिसे embedded runtime पहले ही लिख चुका है।
Control UI agents tools panel
- Control UI
/agentsTools panel में दो अलग-अलग views हैं:- अभी उपलब्ध
tools.effective(sessionKey=...)का उपयोग करता है और current session inventory का server-derived read-only projection दिखाता है, जिसमें core, Plugin, channel-owned, और पहले से खोजे गए MCP server tools शामिल हैं। - Tool Configuration
tools.catalogका उपयोग करता है और profiles, overrides, और catalog semantics पर केंद्रित रहता है।
- अभी उपलब्ध
- Runtime availability session-scoped है। उसी agent पर sessions बदलने से अभी उपलब्ध सूची बदल सकती है। यदि configured MCP servers connect नहीं हुए हैं या last discovery के बाद बदले गए हैं, तो panel read path से चुपचाप MCP transports शुरू करने के बजाय notice दिखाता है।
- config editor runtime availability का संकेत नहीं देता; effective access अब भी policy
precedence (
allow/deny, per-agent और provider/channel overrides) का पालन करता है।
दूरस्थ उपयोग
- Remote mode Gateway WebSocket को SSH/Tailscale पर tunnel करता है।
- आपको अलग WebChat server चलाने की आवश्यकता नहीं है।
Configuration reference (WebChat)
पूरी configuration: Configuration
WebChat में कोई persisted config section नहीं है। Gateway built-in chat.history display limit का उपयोग करता है; API clients किसी एक chat.history call के लिए उसे override करने हेतु per-request maxChars भेज सकते हैं। Legacy channels.webchat और gateway.webchat config retire हो चुका है; इसे हटाने के लिए openclaw doctor --fix चलाएँ।
संबंधित global options:
gateway.port,gateway.bind: WebSocket host/port।gateway.auth.mode,gateway.auth.token,gateway.auth.password: shared-secret WebSocket auth।gateway.auth.allowTailscale: सक्षम होने पर browser Control UI chat tab Tailscale Serve identity headers का उपयोग कर सकता है।gateway.auth.mode: "trusted-proxy": identity-aware non-loopback proxy source के पीछे browser clients के लिए reverse-proxy auth (Trusted Proxy Auth देखें)।gateway.remote.url,gateway.remote.token,gateway.remote.password: remote Gateway target।session.*: session storage और main key defaults।