oc-path Plugin openclaw path CLI को
oc:// workspace-file एड्रेसिंग स्कीम के लिए जोड़ता है। यह OpenClaw रिपॉज़िटरी में
extensions/oc-path/ के अंतर्गत आता है, लेकिन opt-in है — install/build इसे तब तक निष्क्रिय छोड़ता है जब तक आप
इसे सक्षम नहीं करते।
oc:// पते workspace file के अंदर किसी एक leaf (या leaves के wildcard set) की ओर संकेत करते हैं।
Plugin आज चार तरह की फ़ाइलों को समझता है:
- markdown (
.md,.mdx): frontmatter, sections, items, fields - jsonc (
.jsonc,.json5,.json): comments और formatting संरक्षित रहती है - jsonl (
.jsonl,.ndjson): line-oriented records - yaml (
.yaml,.yml,.lobster): YAML document API के ज़रिए map/sequence/scalar nodes
इसे क्यों सक्षम करें
oc-path को तब सक्षम करें जब आप scripts, hooks, या local agent tooling को हर file
shape के लिए parser बनाए बिना workspace state के किसी सटीक हिस्से की ओर संकेत करवाना चाहते हों।
एक oc:// पता markdown frontmatter key, section
item, JSONC config leaf, JSONL event field, या YAML workflow step को नाम दे सकता है।
यह maintainer workflows के लिए महत्वपूर्ण है, जहाँ change छोटा,
auditable, और repeatable होना चाहिए: एक value inspect करें, matching records ढूँढें, write का dry-run करें,
फिर comments, line endings, और आसपास की formatting को वैसा ही रखते हुए केवल वही leaf apply करें।
इसे opt-in Plugin रखने से power users को
addressing substrate मिलता है, बिना उन installs के core में parser dependencies या CLI surface डाले
जिन्हें इसकी कभी ज़रूरत नहीं होती।
इसे सक्षम करने के सामान्य कारण:
- Local automation: shell scripts अलग-अलग markdown, JSONC,
JSONL, और YAML parsing code रखने के बजाय
openclaw path … --jsonसे एक workspace value resolve या update कर सकते हैं। - Agent-visible edits: agent लिखने से पहले किसी एक addressed leaf के लिए dry-run diff दिखा सकता है, जिसकी review free-form file rewrite से आसान होती है।
- Editor integrations: editor
oc://AGENTS.md/tools/ghको heading text से अनुमान लगाए बिना exact markdown node और line number पर map कर सकता है। - Diagnostics:
emitफ़ाइल को parser और emitter के ज़रिए round-trip करता है, ताकि automated edits पर निर्भर होने से पहले आप जाँच सकें कि file kind byte-stable है या नहीं।
oc-path वह संकीर्ण
addressing और byte-preserving file operation layer है जिसके आसपास वे higher-level tools
बन सकते हैं।
यह कहाँ चलता है
Plugin उस host परopenclaw CLI के अंदर in-process चलता है जहाँ आप
command invoke करते हैं। इसे running Gateway की ज़रूरत नहीं होती और यह कोई
network sockets नहीं खोलता — हर verb उस file पर pure transform है जिसकी ओर आप इसे point करते हैं।
Plugin metadata extensions/oc-path/openclaw.plugin.json में रहता है:
onStartup: false Plugin को Gateway hot path से बाहर रखता है। onCommands: ["path"] CLI को बताता है कि पहली बार openclaw path … चलाने पर Plugin को lazily load करे,
इसलिए जो installs इस verb का कभी उपयोग नहीं करते, उन्हें कोई cost नहीं देनी पड़ती।
सक्षम करें
openclaw path invocations उसी host पर तुरंत काम करते हैं —
CLI मांग पर Plugin load करता है।
Disable करने के लिए:
Dependencies
सभी parser dependencies Plugin-local हैं —oc-path सक्षम करने से core runtime में
नए packages नहीं आते:
| Dependency | उद्देश्य |
|---|---|
commander | resolve, find, set, validate, emit के लिए subcommand wiring। |
jsonc-parser | comments और trailing commas रखते हुए JSONC parse + leaf edits। |
markdown-it | section / item / field model के लिए Markdown tokenization। |
yaml | comments और flow style रखते हुए YAML Document parse / emit / edit। |
jsonc-parser से गुजरता है।
यह क्या देता है
| Surface | इससे मिलता है |
|---|---|
openclaw path CLI | extensions/oc-path/cli-registration.ts |
oc:// parser / formatter | extensions/oc-path/src/oc-path/oc-path.ts |
| Per-kind parse / emit / edit | extensions/oc-path/src/oc-path/{md,jsonc,jsonl,yaml} |
| Universal resolve / find / set | extensions/oc-path/src/oc-path/{resolve,find,edit}.ts |
| Redaction-sentinel guard | extensions/oc-path/src/oc-path/sentinel.ts |
दूसरे plugins से संबंध
memory-*: memory writesoc-pathसे नहीं, memory plugins से गुजरते हैं।oc-pathgeneric file substrate है; memory plugins इसके ऊपर अपनी semantics layer करते हैं।- LKG:
pathLast-Known-Good config restore के बारे में नहीं जानता। यदि कोई file LKG-tracked है, तो अगलाobservecall तय करता है कि promote करना है या recover; LKG promote/recover lifecycle के ज़रिए atomic multi-set के लिएset --batchLKG-recovery substrate के साथ planned है।
Safety
set substrate के emit path के ज़रिए raw bytes लिखता है, जो
redaction-sentinel guard को automatically apply करता है। ऐसा leaf जिसमें
__OPENCLAW_REDACTED__ (verbatim या substring के रूप में) हो, write time पर
OC_EMIT_SENTINEL के साथ refuse कर दिया जाता है। CLI अपने द्वारा print किए गए किसी भी
human या JSON output से literal sentinel को scrub भी करता है, उसे [REDACTED] से replace करता है ताकि terminal
captures और pipelines marker leak न करें।