लेखक: Matt Connor 2026-08-05 · अपडेट किया गया: 2026-08-13

OpenTag को VPS पर कैसे host करें

Q: OpenTag को GitHub की कौन सी अनुमतियाँ चाहिए?

Only select repositories तक सीमित एक fine-grained personal access token, जिसमें Issues: Read and write और Pull requests: Read and write की अनुमति हो। यह उल्लेख (mention) पढ़ने और थ्रेड में उत्तर देने के लिए पर्याप्त है। कोड के लिए write access की आवश्यकता तब तक नहीं है जब तक आप preparePullRequestBranch को true पर सेट न करें ताकि OpenTag ब्रांच पुश कर सके। एक अलग githubApplyToken मौजूद है ताकि कोड लिखने वाला टोकन कमेंट करने वाले टोकन से अलग रहे। contents write वाली all-repositories टोकन का उपयोग करने से बचें, क्योंकि उन repositories में कमेंट करने वाला कोई भी व्यक्ति उस एजेंट को नियंत्रित कर सकता है जो कमिट करने में सक्षम है।

Q: गलत दिशा में जा रहे रन को मैं कैसे रोकूँ?

Slack में इसके लिए एक /stop कमांड है। सर्वर पर, opentag status दिखाता है कि क्या चल रहा है, और opentag service stop डेमन को रोक देता है, जो एक रन के बजाय पूरी पाइपलाइन को समाप्त कर देता है। इन दोनों की आवश्यकता से बचने के लिए, approvalMode को ask पर सेट करें ताकि कुछ भी बदलने से पहले रन किसी व्यक्ति के लिए रुक जाए, और preparePullRequestBranch को false पर रखें ताकि एक खराब रन ब्रांच बनाने के बजाय केवल एक कमेंट उत्पन्न करे।

Slack और GitHub mentions को अपने coding agent तक पहुँचाने के लिए OpenTag को VPS पर सेटअप करें। TLS ingress, webhook signature, और token scopes को सुरक्षित रूप से कॉन्फ़िगर करें।

जब आप किसी agent का उल्लेख करते हैं तो OpenTag क्या करता है

OpenTag Slack thread या GitHub issue में किए गए @mention को आपके अपने मशीन पर चलने वाले एक coding agent में बदल देता है। जब कोई किसी issue पर @opentag investigate this टिप्पणी करता है, तो एक listener उस platform event को प्राप्त करता है, उसके signature की जाँच करता है, mention को एक bound project से मिलाता है, local checkout पर एक coding agent शुरू करता है, और परिणाम को उसी thread में वापस पोस्ट कर देता है।

यह project MIT licensed है और amplifthq/opentag पर उपलब्ध है। अगस्त 2026 तक, नवीनतम tagged release v0.9.0 है, जिसे 28 जुलाई 2026 को प्रकाशित किया गया था, और यह एक npm package के रूप में उपलब्ध है। इसका कोई आधिकारिक container image नहीं है, इसलिए आप जिस version को pin करते हैं वह npm version है। नीचे दिए गए सभी commands इसे pin करते हैं।

GitHub के कारण यह एक laptop project के बजाय एक VPS project बन जाता है। GitHub repository events को एक ऐसे URL पर HTTP request भेजकर deliver करता है जिसे आप एक बार register करते हैं, इसलिए उस URL को कल भी उसी address पर जवाब देने में सक्षम होना चाहिए।

चार गतिशील घटक

Listener प्लेटफॉर्म इवेंट्स को प्राप्त करता है, और प्रत्येक प्लेटफॉर्म के अपने इवेंट्स होते हैं। GitHub listener पोर्ट 3050 पर /github/webhooks पाथ पर एक HTTP एंडपॉइंट है। Slack Events API listener पोर्ट 3040 पर /slack/events पर स्थित है। Slack को Socket Mode में भी चलाया जा सकता है, जहाँ ऐप एक आउटबाउंड WebSocket खोलता है और उसे किसी भी इनबाउंड पोर्ट की आवश्यकता नहीं होती है।

Dispatcher समन्वयक (coordinator) है। यह डिफ़ॉल्ट रूप से पोर्ट 3030 पर लिसन करता है, रन स्टेट को OPENTAG_DATABASE_PATH द्वारा सेट की गई लोकल डेटाबेस फ़ाइल में रखता है, और प्रत्येक रन के लिए एक ऑडिट ट्रेल रिकॉर्ड करता है। बॉक्स के बाहर की किसी भी चीज़ को इस पोर्ट तक कभी नहीं पहुँचना चाहिए।

Runner लोकल डेमन है। यह काम के लिए पोलिंग करता है, रन का दावा (claim) करता है, उस पर लीज रखता है, और रन के सक्रिय रहने के दौरान डिफ़ॉल्ट रूप से हर 15 सेकंड में एक हार्टबीट भेजता है। यह किसी भी ऐसे क्लेम किए गए रन को अस्वीकार कर देता है जिसका प्रोजेक्ट टारगेट गायब हो या उसके अपने कॉन्फ़िगरेशन में अलाउलिस्ट से बाहर हो; यह वह जाँच है जो GitHub इवेंट को आपके एजेंट को किसी ऐसी रिपॉजिटरी की ओर इशारा करने से रोकती है जिसे आपने कभी बाइंड नहीं किया था।

Executor स्वयं कोडिंग एजेंट है। OpenTag इसे ACP (agent client protocol) के माध्यम से लॉन्च करता है, जो स्टैंडर्ड इनपुट और आउटपुट पर उपयोग किया जाने वाला एक JSON-RPC प्रोटोकॉल है, इसलिए एजेंट OpenTag द्वारा दिए गए वर्किंग डायरेक्टरी के अंदर एक चाइल्ड प्रोसेस के रूप में चलता है। इन-बिल्ट नामों में echo, codex, claude-code, cursor, opencode, hermes और openclaw शामिल हैं। echo के साथ शुरुआत करें, जो कि वह एक्जीक्यूटर है जिसके साथ उदाहरण कॉन्फ़िगरेशन आता है, क्योंकि यह साबित करता है कि कोई मॉडल आपके कोड को छूने से पहले पूरा पाथ काम कर रहा है।

क्रम कभी नहीं बदलता: प्लेटफॉर्म इवेंट, सिग्नेचर चेक, रन रिकॉर्ड, क्लेम, एजेंट, थ्रेड में रिप्लाई।

लैपटॉप और टनल पर्याप्त क्यों नहीं हैं

GitHub सेटअप गाइड आपको ngrok http 3050 चलाने और टनल होस्ट को रिपॉजिटरी वेबहुक में पेस्ट करने के लिए कहती है। यह पहले दस मिनट के लिए काम करता है। एक फ्री टनल होस्ट हर बार प्रोसेस रीस्टार्ट होने पर बदल जाता है, और लैपटॉप के स्लीप मोड में जाने पर यह काम करना बंद कर देता है। GitHub पुरानी पेलोड URL को बनाए रखता है और उसे बार-बार ट्राई करता रहता है, इसलिए वेबहुक सेटिंग्स में Recent Deliveries टैब विफलताओं से भर जाता है जबकि थ्रेड शांत रहता है। एक सप्ताह तक किसी को पता नहीं चलता, क्योंकि जो वेबहुक कुछ नहीं करता, वह बिल्कुल उस बॉट जैसा दिखता है जिसका किसी ने जिक्र ही नहीं किया।

एक VPS उन दो चीजों को ठीक करता है जो खराब हो जाती हैं। DNS नाम नहीं बदलता है, इसलिए जो पेलोड URL आप एक बार पेस्ट करते हैं वह सही बनी रहती है। मशीन स्लीप मोड में नहीं जाती है, इसलिए 02:00 बजे आने वाली किसी टिप्पणी का जवाब मिल जाता है। पहले बॉक्स को ठीक से सेटअप करें: नए VPS पर पहले दस मिनट में लॉगिन यूजर और फायरवॉल को कवर किया गया है जिसे यह गाइड मानकर चलती है।

Slack एक अपवाद है। Socket Mode में यह बाहर की ओर कनेक्ट होता है और इसे किसी पब्लिक URL की आवश्यकता नहीं होती है, इसलिए केवल Slack वाला डिप्लॉयमेंट बंद (closed) रह सकता है। GitHub में इसका कोई समकक्ष नहीं है। रिपॉजिटरी वेबहुक इनबाउंड HTTP होते हैं, जिसका अर्थ है एक पब्लिक एंडपॉइंट, और इसका अर्थ है TLS (ट्रांसपोर्ट लेयर सिक्योरिटी) और सिग्नेचर चेक।

Ubuntu पर pinned release से OpenTag को self-host करना

OpenTag v0.9.0 के लिए Node.js 22 या उससे नया वर्ज़न आवश्यक है। Ubuntu 24.04 अपने रिपॉजिटरी में Node 18 प्रदान करता है, इसलिए इसे NodeSource से इंस्टॉल करें।

curl -fsSL https://deb.nodesource.com/setup_22.x -o nodesource_setup.sh
sudo -E bash nodesource_setup.sh
sudo apt install -y nodejs
node -v

node -v को v22 या उससे अधिक प्रिंट करना चाहिए। Node 20 पर इंस्टॉलेशन एक EBADENGINE चेतावनी देता है और CLI शुरू होने पर विफल हो सकता है।

सर्विस को अपना स्वयं का अकाउंट दें। एजेंट इस यूजर की अनुमतियों के साथ चलता है, इसलिए यह आपका लॉगिन नहीं होना चाहिए और न ही यह root होना चाहिए। VPS पर Least privilege users यह बताता है कि यह अलगाव अतिरिक्त प्रयास के लायक क्यों है।

sudo adduser --disabled-password --gecos "" opentag
sudo loginctl enable-linger opentag
sudo npm install -g @opentag/cli@0.9.0
command -v opentag

command -v opentag को /usr/bin/opentag जैसा पाथ प्रिंट करना चाहिए। Linux पर linger सेटिंग महत्वपूर्ण है: OpenTag अपनी बैकग्राउंड सर्विस को systemd के माध्यम से इंस्टॉल करता है, और बिना linger के यूजर सर्विस आपके SSH सेशन के बंद होते ही रुक जाती है।

उस यूजर के रूप में सेटअप चलाएं।

sudo -iu opentag opentag setup

सेटअप छह चीजें पूछता है: CLI भाषा, लोकल लिसनिंग एड्रेस, कोडिंग एजेंट, काम करने के लिए लोकल प्रोजेक्ट, सेव करने के लिए प्लेटफॉर्म क्रेडेंशियल्स, और चलाने का तरीका। लिसनिंग एड्रेस को 127.0.0.1 पर रखें, क्योंकि Nginx TLS को टर्मिनेट करता है और इसे फॉरवर्ड करता है, इसलिए लिसनर्स को बाहर से एक्सेस करने योग्य होने की आवश्यकता नहीं है। GitHub के लिए यह owner/repo फॉर्मेट में रिपॉजिटरी, क्या यह पुल रिक्वेस्ट खोल सकता है, वेबहुक पोर्ट (डिफ़ॉल्ट रूप से 3050) और टोकन के बारे में भी पूछता है। अंत में बैकग्राउंड सर्विस मोड चुनें। यदि आपके पास पहले से ही कॉन्फ़िगरेशन है और आप बिना प्रॉम्प्ट के सर्विस इंस्टॉल करना चाहते हैं, तो opentag setup --service ऐसा करता है।

कॉन्फ़िगरेशन /home/opentag/.config/opentag/config.json में और रनटाइम स्टेट /home/opentag/.local/state/opentag में सेव होता है। सेटअप द्वारा फाइल लिखने के बाद इन कुंजियों को मैन्युअल रूप से जांचना उचित है।

{
  "runnerId": "runner_local",
  "dispatcherUrl": "http://localhost:3030",
  "runnerToken": "...",
  "approvalMode": "ask",
  "repositories": []
}

पुराने शेयर्ड pairingToken के बजाय रनर-स्कोप वाले बेयरर टोकन runnerToken को प्राथमिकता दें। कॉन्फ़िगरेशन फाइल क्रेडेंशियल्स को प्लेन टेक्स्ट में रखती है जब तक कि आप उन्हें सीक्रेट रेफरेंस से न बदल दें, जो स्टार्टअप पर एनवायरनमेंट या डिस्क पर मौजूद फाइल से वैल्यू पढ़ता है। किसी भी स्थिति में, यह फाइल बॉक्स पर सबसे संवेदनशील चीज है: मोड 600, opentag के स्वामित्व में, और कभी भी git रिपॉजिटरी के अंदर नहीं। इस पर विस्तृत तर्क AI एजेंटों से सीक्रेट्स को दूर रखना में है।

किसी भी चीज को एक्सपोज करने से पहले इंस्टॉलेशन की जांच करें।

sudo -iu opentag opentag doctor
sudo -iu opentag opentag status

opentag doctor डिस्पैचर, बाइंडिंग्स, चेकआउट्स और एग्जीक्यूटर्स की जांच करता है। opentag status कॉन्फ़िगरेशन और रनटाइम स्टेट को प्रिंट करता है, और रन मौजूद होने पर इसे एक सिंगल रन तक सीमित किया जा सकता है। इससे पहले कि आप किसी प्लेटफॉर्म को इस बॉक्स पर पॉइंट करें, doctor द्वारा रिपोर्ट की गई हर चीज को ठीक करें।

TLS को सामने रखें और केवल दो paths खोलें

nginx TLS को terminate करता है और केवल दो paths को forward करता है। बाकी सब कुछ 404 return करता है, इसलिए host को खोजने वाला scanner यह नहीं जान पाता कि उसके पीछे क्या चल रहा है।

/etc/nginx/sites-available/opentag पर एक plain port 80 server block लिखें जिसमें नीचे दिए गए दो locations हों, फिर Certbot को TLS वाला हिस्सा जोड़ने दें।

sudo apt install -y nginx certbot python3-certbot-nginx
sudo ln -s /etc/nginx/sites-available/opentag /etc/nginx/sites-enabled/opentag
sudo nginx -t && sudo systemctl reload nginx
sudo certbot --nginx -d opentag.example.com

nginx -t, syntax is ok और test is successful को print करता है, और यह एक typo और ऐसी reload के बीच एकमात्र सुरक्षा है जो साइट को down कर सकती है। Ubuntu 24.04 पर nginx के साथ Certbot renewal और उन तरीकों को कवर करता है जिनसे ACME (automatic certificate management environment) challenge विफल हो सकता है। तैयार block कुछ इस तरह दिखता है।

server {
    listen 443 ssl;
    server_name opentag.example.com;

    ssl_certificate     /etc/letsencrypt/live/opentag.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/opentag.example.com/privkey.pem;

    client_max_body_size 2m;

    location = /github/webhooks {
        proxy_pass http://127.0.0.1:3050;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto https;
    }

    location = /slack/events {
        proxy_pass http://127.0.0.1:3040;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto https;
    }

    location / {
        return 404;
    }
}

location = /github/webhooks में = एक exact match है, और port के बाद कुछ न होने पर proxy_pass मूल URI को बिना किसी बदलाव के pass कर देता है। = को हटा दें और /github/webhooks/ के अंतर्गत आने वाला हर path भी forward हो जाता है, जो listener की आवश्यकता से अधिक surface area है।

Firewall को सीमित रखें।

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw status

Ports 3030, 3040 और 3050 कभी न खोलें। पुष्टि करें कि वे हर interface के बजाय loopback पर bound हैं।

sudo ss -tlnp

हर OpenTag line को 127.0.0.1:3030 या उसके समान होना चाहिए। 0.0.0.0:3050 पढ़ने वाली line का मतलब है कि listener खुद को पूरे internet के लिए पेश कर रहा है और केवल ufw उसे रोक रहा है, जो कि एक firewall गलती से open agent trigger का कारण बन सकता है। ufw firewall basics बताता है कि वह default deny वास्तव में क्या कर रहा है।

दो जाँचें मुख्य द्वार को प्रमाणित करती हैं। curl -I https://opentag.example.com/, nginx से 404 return करता है, जो दर्शाता है कि certificate valid है और catch-all बंद है। बिना signature वाले /slack/events या /github/webhooks पर किया गया request कभी भी 200 return नहीं करना चाहिए।

हर signature की पुष्टि करें, क्योंकि URL सार्वजनिक है

कोई भी व्यक्ति payload URL को ढूंढ सकता है। यह आपके repository settings, browser history, या किसी ticket में पेस्ट किए गए screenshot में मौजूद होता है। signature ही वह एकमात्र चीज है जो एक वास्तविक GitHub delivery को किसी व्यक्ति द्वारा हाथ से टाइप किए गए request से अलग करती है।

GitHub प्रत्येक delivery को webhook secret के साथ sign करता है और परिणाम को x-hub-signature-256 header में भेजता है। OpenTag उस header की पुष्टि platforms.github.webhookSecret के विरुद्ध करता है। प्रोजेक्ट के hardening notes इस नियम को सीधे तौर पर बताते हैं: /github/webhooks पर unsigned source events को स्वीकार न करें। Slack प्रत्येक request को SLACK_SIGNING_SECRET के साथ sign करता है और एक timestamp शामिल करता है, ताकि capture किए गए body को घंटों बाद फिर से replay न किया जा सके।

इसे छोड़ना कोई छोटा जोखिम नहीं है। एक unverified endpoint हाथ से लिखे गए issue_comment payload को स्वीकार कर लेता है जिसमें @opentag शामिल होता है, और फिर OpenTag एक अजनबी के निर्देशों पर, आपके token के साथ, आपके checkout में एक coding agent चला देता है। उत्तर उस thread पर जाता है जिसे fake payload में नामित किया गया है।

OpenTag इसके ऊपर दो परतें जोड़ता है। Source deliveries को delivery ID द्वारा track किया जाता है, इसलिए एक ही event को दोबारा भेजने से दूसरा run शुरू नहीं होता है। Runner calls idempotency keys को स्वीकार करते हैं, इसलिए एक को replay करने पर दूसरा audit event जोड़े बिना सफलता का संदेश मिलता है।

Rate limits कॉन्फ़िगर करने योग्य हैं और इन्हें चालू रखा जाना चाहिए। OPENTAG_RATE_LIMIT_WINDOW_MS और OPENTAG_RATE_LIMIT_MAX_REQUESTS request rate को सीमित करते हैं, OPENTAG_MAX_REQUEST_BODY_BYTES body को सीमित करता है, और एक बहुत बड़े payload को 413 request_body_too_large के साथ अस्वीकार कर दिया जाता है। OPENTAG_RATE_LIMIT_DISABLED=true स्थानीय विकास के लिए मौजूद है, और सार्वजनिक बॉक्स पर इसका कोई स्थान नहीं है। उन्हीं नोट्स से एक और नियम: एक सार्वजनिक relay URL को HTTPS का उपयोग करना चाहिए, और CLI केवल localhost के लिए plain HTTP की अनुमति देता है।

बॉट को वास्तव में किन टोकन स्कोप की आवश्यकता होती है?

GitHub पर, OpenTag एक GitHub App के बजाय fine-grained personal access token का उपयोग करता है। दस्तावेज़ बताते हैं कि App पाथ अभी योजनाबद्ध है और वर्तमान में डिफ़ॉल्ट CLI सेटअप नहीं है, और इसका एक परिणाम है जिसे लोग अक्सर अनदेखा कर देते हैं: बॉट उस व्यक्ति के रूप में टिप्पणी करता है जिसने टोकन बनाया है। इसे ऐसे अकाउंट के तहत बनाएं जिसे आप हर triage उत्तर में उद्धृत होते हुए देखने में सहज हों।

इसे सेटअप गाइड के अनुसार ही सीमित रखें। Only select repositories चुनें और एक रिपॉजिटरी चुनें। Issues: Read and write और Pull requests: Read and write अनुमतियाँ दें। किसी उल्लेख को पढ़ने और थ्रेड में उत्तर देने के लिए यह पर्याप्त है।

ध्यान दें कि क्या गायब है: कोड के लिए write access। OpenTag तब तक ब्रांच पुश नहीं करता जब तक कि preparePullRequestBranch को true पर सेट न किया जाए, और एक अलग githubApplyToken मौजूद होता है ताकि कोड लिखने वाला टोकन और टिप्पणी लिखने वाला टोकन अलग-अलग रहें। उन्हें अलग रखें, और write टोकन को तब तक बंद रखें जब तक कि read-and-comment पाथ कुछ हफ़्तों तक न चल जाए।

जिस कॉन्फ़िगरेशन से बचना चाहिए वह है All repositories पर Contents: Read and write वाला टोकन। अब उन सभी रिपॉजिटरी में टिप्पणी करने वाला कोई भी व्यक्ति ऐसे एजेंट को नियंत्रित कर सकता है जिसके पास commit अधिकार हैं, और ऑडिट ट्रेल में यह दिखेगा कि टोकन स्वामी ने ऐसा किया है। एजेंट द्वारा विश्वास अर्जित करने के बाद, एक-एक करके स्कोप बढ़ाएं।

Slack पर बॉट स्कोप app_mentions:read, chat:write, reactions:write और channels:history हैं। प्राइवेट चैनलों के लिए groups:history और message.groups इवेंट के सब्सक्रिप्शन की भी आवश्यकता होती है। Socket Mode के लिए connections:write वाले app-level टोकन की आवश्यकता होती है, जो xapp- से शुरू होता है। channels:history उन पब्लिक चैनलों में संदेश इतिहास पढ़ता है जिनमें बॉट को जोड़ा गया है, इसलिए बॉट को हर जगह जोड़ने के बजाय केवल उन चैनलों में जोड़ें जहाँ इसकी आवश्यकता है।

एक issue के लिए end-to-end route को ट्रैक करें

सबसे पहले webhook आता है। Repository में Settings खोलें, फिर Webhooks पर जाएँ और Add webhook चुनें। Payload URL https://opentag.example.com/github/webhooks है, content type application/json है, और secret वह है जिसे setup ने generate किया था। केवल Issue comments और Pull request review comments को subscribe करें, किसी और को नहीं।

जैसे ही आप save करते हैं, GitHub एक ping delivery भेजता है। Recent Deliveries खोलें और जाँचें कि क्या request सर्वर तक पहुँची है। वहाँ 502 error का मतलब है कि nginx listener तक नहीं पहुँच पा रहा है; यह एक local समस्या है, GitHub की नहीं।

अब इसका उपयोग करें। एक ऐसा issue खोलें जो किसी bug का वर्णन करता हो और उस पर यह comment करें:

@opentag triage this. Reproduce the report against the current main branch, then reply with the file and function most likely responsible, plus the test you would write first.

क्रमवार देखें कि क्या होना चाहिए। Recent Deliveries में issue_comment delivery 2xx response के साथ दर्ज होती है। Dispatcher एक run record करता है। Runner उसे claim करता है और heartbeating शुरू करता है। Executor checkout खोलता है और काम शुरू करता है। उत्तर उसी issue thread में एक comment के रूप में आता है। sudo -iu opentag opentag status run को flight के दौरान दिखाता है, ताकि आप अनुमान लगाने के बजाय उसे देख सकें।

पहले वास्तविक run से पहले approvalMode को ask पर set करें। ask mode में run रुक जाता है और state बदलने वाला कोई भी काम करने से पहले व्यक्ति की प्रतीक्षा करता है। auto और autonomous modes भी मौजूद हैं, और वे बाद में तब उपयोगी होते हैं जब आप किसी repository पर एक महीने के transcripts पढ़ चुके हों।

Slack की तरफ, वही run channel में /bind owner/repo के साथ शुरू होता है, उसके बाद एक mention आता है। Bot /help, /status, /doctor, /stop और /unbind confirm का भी उत्तर देता है। कौन bindings बदल सकता है, इसे OPENTAG_SLACK_BINDING_ADMIN_USER_IDS के साथ सीमित करें। यह Slack user IDs की एक comma-separated list है, क्योंकि binding का मतलब public channel से आपके सर्वर पर मौजूद checkout की mapping है।

Triage एक अच्छा पहला route है क्योंकि यह केवल पढ़ता है, लिखता नहीं है, और इसके उत्तर को grade करना आसान है। Review अगला चरण है, जहाँ agent issue के बजाय diff पर comment करता है: एक self-hosted pull request review agent यही architecture है जो pull requests पर काम करता है। यदि आप चाहते हैं कि agent काम करते समय आपके अपने systems तक पहुँचे, तो यह MCP servers on a VPS का काम है। Web search वह दूसरी क्षमता है जिसे triage बार-बार मांगता है, और agent को अपने SearXNG instance से जोड़ना उन lookups को आपके द्वारा चलाए जा रहे hardware पर रखता है, जिसकी कीमत बस एक अतिरिक्त channel है जिसके माध्यम से किसी अनजान व्यक्ति का text agent तक पहुँचता है।

जब एजेंट सबके सामने गलत जानकारी देता है तो क्या होता है?

यह गलत होगा। सवाल यह है कि इसकी कीमत क्या चुकानी पड़ती है।

किसी सार्वजनिक issue पर गलत जवाब आपकी टीम द्वारा पहचाने जाने वाले नाम के तहत एक टिप्पणी है, और पोस्ट होते ही GitHub इसे सब्सक्राइब करने वाले सभी लोगों को ईमेल कर देता है। टिप्पणी को हटाने से ईमेल वापस नहीं आता। Slack नोटिफिकेशन के साथ भी यही स्थिति है। निजी तौर पर सही होने के बजाय सार्वजनिक रूप से गलत होने की संभावना के लिए योजना बनाएं।

चार विकल्प नुकसान को सीमित करते हैं, और वे आपके द्वारा लिखे गए किसी भी prompt से अधिक महत्वपूर्ण हैं।

ask मोड में चलाएं, ताकि एजेंट प्रस्ताव दे, कोई व्यक्ति उसे मंजूरी दे, और एक गलत योजना की कीमत केवल एक क्लिक हो।
preparePullRequestBranch को इसके डिफ़ॉल्ट मान false पर छोड़ दें, ताकि एक खराब रन का सबसे बुरा परिणाम गलत शाखा (branch) के बजाय एक गलत टिप्पणी हो।
शुरुआत करने के लिए एक repository और एक channel को बाइंड करें। रनर किसी भी ऐसे रन को अस्वीकार कर देता है जिसका प्रोजेक्ट लक्ष्य उसकी स्थानीय allowlist से बाहर है, इसलिए एक unbound repository एजेंट को अपने अंदर नहीं खींच सकती।
commenting token को किसी भी apply token से अलग रखें, ताकि write access रद्द करने से triage की प्रक्रिया प्रभावित न हो।

Slack में गलत दिशा में जा रहे रन के लिए /stop कमांड है। हर रन एक ऑडिट रिकॉर्ड भी छोड़ता है जिसमें वह उल्लेख (mention) होता है जिसने इसे शुरू किया और एजेंट ने क्या किया, जिसे आप बाद में यह पता लगाने के लिए पढ़ते हैं कि गलती कहाँ हुई।

सामाजिक पहलू उतना ही महत्वपूर्ण है जितना कि कॉन्फ़िगरेशन। बॉट को एक ऐसे चैनल में रखें जहाँ लोग मशीन की अपेक्षा रखते हों और जानते हों कि यह गलत हो सकता है। चालीस लोगों के चैनल में एक आत्मविश्वासपूर्ण गलत जवाब, यह मानकर कि किसी इंसान ने इसकी समीक्षा की है, triage द्वारा बचाए गए समय से अधिक महंगा पड़ता है। चैनल विवरण में लिखें कि बॉट का मालिक कौन है और इसके आउटपुट की जाँच कौन करता है।

Backups, upgrades and the pin

सब कुछ दो paths में सुरक्षित रहता है: /home/opentag/.config/opentag/config.json और /home/opentag/.local/state/opentag। पहले में आपके credentials होते हैं, और दूसरे में run history तथा database file होती है। दोनों का backup mode 600 के साथ लें और उन्हें सर्वर से बाहर कहीं सुरक्षित रखें। इनके खोने का अर्थ है tokens और bindings को फिर से बनाना, न कि पूरे सर्वर को फिर से तैयार करना।

Upgrades का अर्थ है version को बढ़ाना और service को restart करना।

sudo npm install -g @opentag/cli@0.9.0
sudo -iu opentag opentag service stop
sudo -iu opentag opentag service start
sudo -iu opentag opentag doctor

@latest को track करने के बजाय version को pin करें। यह software एक live token के साथ आपके repository पर coding agent चलाता है, इसलिए रात भर में publish हुआ कोई भी नया release आपके लिए एक बिना जाँचा गया बदलाव हो सकता है। Security policy में पुराने versions के लिए कोई backport नहीं दिया जाता है, और सुधार केवल नवीनतम release में ही आते हैं। इसलिए, pin करने का अर्थ है कि आप changelog पढ़ते हैं और सोच-समझकर आगे बढ़ते हैं। इसका अर्थ यह नहीं है कि आप हमेशा v0.9.0 पर ही बने रहें। July 2026 तक का इतिहास दिखाता है कि हर महीने कई releases आते हैं, जो कि हर upgrade से पहले release notes पढ़ने का एक ठोस कारण है।

FAQ

क्या OpenTag चलाने के लिए VPS जरूरी है, या लैपटॉप काफी है?

केवल Slack के लिए लैपटॉप काफी है, क्योंकि Socket Mode एक outbound WebSocket खोलता है और इसके लिए किसी inbound port की आवश्यकता नहीं होती। GitHub के मामले में स्थिति अलग है। Repository webhooks एक inbound HTTP के माध्यम से उस URL पर डिलीवर होते हैं जिसे आप एक बार रजिस्टर करते हैं, इसलिए पता स्थिर रहना चाहिए और आपके सो जाने पर भी उसे जवाब देना चाहिए। एक मुफ्त अकाउंट का tunnel host हर रीस्टार्ट पर बदल जाता है, और GitHub पुराने पते पर ही पोस्ट करता रहता है। यह repository के Recent Deliveries टैब में विफल प्रविष्टियों के रूप में दिखाई देता है और थ्रेड में कोई प्रतिक्रिया नहीं मिलती। एक स्थिर DNS नाम और certificate वाला VPS इन दोनों समस्याओं को दूर करता है।

OpenTag को GitHub की कौन सी अनुमतियाँ चाहिए?

Only select repositories तक सीमित एक fine-grained personal access token, जिसमें Issues: Read and write और Pull requests: Read and write की अनुमति हो। यह उल्लेख (mention) पढ़ने और थ्रेड में उत्तर देने के लिए पर्याप्त है। कोड के लिए write access की आवश्यकता तब तक नहीं है जब तक आप preparePullRequestBranch को true पर सेट न करें ताकि OpenTag ब्रांच पुश कर सके। एक अलग githubApplyToken मौजूद है ताकि कोड लिखने वाला टोकन कमेंट करने वाले टोकन से अलग रहे। contents write वाली all-repositories टोकन का उपयोग करने से बचें, क्योंकि उन repositories में कमेंट करने वाला कोई भी व्यक्ति उस एजेंट को नियंत्रित कर सकता है जो कमिट करने में सक्षम है।

गलत दिशा में जा रहे रन को मैं कैसे रोकूँ?

Slack में इसके लिए एक /stop कमांड है। सर्वर पर, opentag status दिखाता है कि क्या चल रहा है, और opentag service stop डेमन को रोक देता है, जो एक रन के बजाय पूरी पाइपलाइन को समाप्त कर देता है। इन दोनों की आवश्यकता से बचने के लिए, approvalMode को ask पर सेट करें ताकि कुछ भी बदलने से पहले रन किसी व्यक्ति के लिए रुक जाए, और preparePullRequestBranch को false पर रखें ताकि एक खराब रन ब्रांच बनाने के बजाय केवल एक कमेंट उत्पन्न करे।

मेरा webhook 502 क्यों लौटा रहा है जबकि थ्रेड शांत है?

502 त्रुटि OpenTag से नहीं, बल्कि nginx से आती है, और इसका मतलब है कि प्रॉक्सी listener तक नहीं पहुँच सका। /var/log/nginx/error.log से connect() failed (111: Connection refused) while connecting to upstream दिखाई देगा। या तो listener बंद है, या वह उस पोर्ट पर नहीं है जिसे proxy_pass लाइन में निर्दिष्ट किया गया है। sudo ss -tlnp चलाएँ और पुष्टि करें कि GitHub के लिए 127.0.0.1:3050 और Slack के लिए 127.0.0.1:3040 पर कुछ सुन (listen) रहा है, फिर बाइंडिंग और निष्पादकों (executors) के लिए opentag doctor चलाएँ।

#opentag#ai-agents#slack#github#webhooks#सेल्फ़-होस्टिंग