आपके agents एक असली browser चलाते हैं।
नकली नहीं।
AgentsRoom हर प्रोजेक्ट में एक असली Chromium ब्राउज़र एम्बेड करता है, और साथ में एक AgentsRoom Browser MCP सर्वर देता है जो आपके AI एजेंट्स को उसे चलाने देता है। आपका QA एजेंट आपकी localhost साइट खोलता है, बटन क्लिक करता है, फ़ॉर्म भरता है, स्क्रीनशॉट लेता है, कंसोल पढ़ता है, और काम पूरा बताने से पहले जाँचता है कि फ़ीचर वाकई काम कर रहा है। Claude Code, Codex, OpenCode, Antigravity CLI, Aider, Grok Build, Mistral Vibe और Kimi Code के लिए end-to-end ब्राउज़र ऑटोमेशन, बिना किसी Playwright कॉन्फ़िगरेशन के।
Agent Teams के साथ pair करें: एक Dev agent feature ship करता है, एक QA agent embedded browser में localhost site load करता है, verification scenario run करता है, result screenshot करता है, और sign off करता है। Native browser automation भी roadmap पर है, future MCP servers React Native और Electron apps के लिए planned हैं ताकि agents mobile और desktop apps भी test कर सकें।
AgentsRoom Browser MCP डेमो: embedded Chromium browser के ज़रिए एक Claude Code QA agent द्वारा संचालित end-to-end web app testing।
AgentsRoom में Browser Automation एक साथ दो चीज़ें है। पहली: हर प्रोजेक्ट रूम में एम्बेड किया गया एक असली Chromium ब्राउज़र, URL बार, बैक/फ़ॉरवर्ड, रीलोड, हिस्ट्री, क्लिपबोर्ड पर स्क्रीनशॉट, डिफ़ॉल्ट ब्राउज़र में खोलना, और हर प्रोजेक्ट के लिए अलग कुकीज़ तथा localStorage के साथ। दूसरी: एक AgentsRoom Browser MCP सर्वर (agentsroom-browser) जो उस ब्राउज़र को Model Context Protocol के ज़रिए आपके AI एजेंट्स के सामने खोलता है। एजेंट को एक साफ़, स्क्रिप्ट करने लायक इंटरफ़ेस मिलता है: navigate, click, type, screenshot, JavaScript evaluate करना, किसी एलिमेंट का इंतज़ार करना, पेज स्टेट लेना, कंसोल लॉग्स लेना, back, forward, reload।
यह क्यों matter करता है? क्योंकि AI coding agents का पूरा वादा तब बिखर जाता है जब agent कहता है 'feature shipped' लेकिन check करने के लिए कभी page नहीं खोलता। आज के ज़्यादातर agents unit tests चलाने पर निर्भर हैं, फिर वे hope करते हैं। एक असली browser MCP के साथ, agent localhost server load करता है, user flow exercise करता है, वही देखता है जो human user देखता। और तभी sign off करता है। QA Engineer agent role के पास आखिरकार वे tools हैं जो उसे real QA करने के लिए चाहिए, सिर्फ static analysis नहीं।
Technical setup आपके लिए invisible है। जब आप एक agent पर 'Browser access' tick करते हैं, AgentsRoom आपके project के .mcp.json में agentsroom-browser entry merge कर देता है और agent browser tools के साथ boot होता है। एक loopback port पर चलता एक WebSocket bridge (127.0.0.1, OS-assigned, हर boot पर regenerated, 32-byte hex token से authenticated) MCP subprocess को Electron app में Chromium WebContentsView से connect करता है। हर click, हर type, हर screenshot एक JSON-RPC call है। Agent एक असली browser देखता है, कोई stub नहीं।
AgentsRoom Browser पैनल: URL बार, हिस्ट्री, स्क्रीनशॉट, और AI एजेंट्स के लिए पूरा MCP कंट्रोल सरफ़ेस, ताकि वे navigate, click, type और verify कर सकें।
एक असली browser, Playwright stub नहीं
ब्राउज़र ऑटोमेशन की बात करने वाले ज़्यादातर AI एजेंट डेमो हर टूल कॉल पर एक हेडलेस Playwright इंस्टेंस स्पॉन करते हैं। बेंचमार्क के लिए यह चल जाता है, पर असल ज़िंदगी में तकलीफ़देह है: आप देख ही नहीं सकते कि एजेंट क्या कर रहा है, हर नेविगेशन Chromium को दोबारा शुरू करता है, कुकीज़ खो जाती हैं, localStorage खाली रहता है, और आपका dev सर्वर हर विज़िट को बिल्कुल नया सेशन समझता है। AgentsRoom अलग रास्ता लेता है। ब्राउज़र आपके प्रोजेक्ट रूम में पहले से खुला रहता है (आप खुद उसे एक सामान्य ब्राउज़र की तरह इस्तेमाल करते हैं), और एजेंट उसी ब्राउज़र को चलाता है। सेशन, कुकीज़, localStorage, लॉगिन स्टेट: सब बना रहता है।
एजेंट का हर क्लिक और हर टाइप Electron के WebContentsView के ज़रिए एक असली नेटिव डिस्पैच ट्रिगर करता है, सही की-इवेंट्स, माउस इवेंट्स और DOM म्यूटेशन के साथ। स्क्रीनशॉट असली PNG होते हैं, जो सचमुच रेंडर हुए पेज से लिए जाते हैं (कोई DOM-to-image जुगाड़ नहीं)। कंसोल लॉग्स बफ़र होते हैं और उन्हें क्वेरी किया जा सकता है, वॉर्निंग और एरर समेत। एजेंट वही देखता है जो आप DevTools खुले होने पर देखते: असली परफ़ॉर्मेंस, असली नेटवर्क व्यवहार, असली CORS, असली ऑथ।
Cross-room isolation enforce होता है। AgentsRoom हर project के लिए एक Chromium WebContentsView बनाता है, अपने session partition (persist:agentsroom-browser-<projectId>) के साथ। Project A के cookies project B में कभी leak नहीं होते। जब आप project switch करते हैं, पिछला browser hide होता है और नया अपनी state के साथ online आता है। Agent हमेशा correct project पर, correct credentials के साथ land करता है।
MCP लेयर जान-बूझकर छोटी और डिपेंडेंसी-फ़्री रखी गई है। browser-mcp-server.cjs सबप्रोसेस stdio पर MCP 2024-11-05 प्रोटोकॉल बोलता है (initialize, tools/list, tools/call) और उसे लूपबैक WebSocket ब्रिज पर JSON-RPC कॉल्स में बदल देता है। किसी भारी SDK-आधारित सर्वर के मुकाबले यह तेज़ रहता है (पहला टूल कॉल 100ms से कम) और डीबग करना आसान है। पेज बदलने वाली हर कार्रवाई के बाद (click, type, navigate, reload, back, forward) रिस्पॉन्स में 1.6 MB तक सीमित एक base64 PNG स्क्रीनशॉट शामिल होता है, ताकि एजेंट हमेशा देख सके कि उसने अभी जो किया उसका नतीजा क्या रहा। भरोसेमंदी के लिहाज़ से यही सबसे बड़ी जीत साबित हुई: जो एजेंट्स स्क्रीन देखते हैं, वे उम्मीद के भरोसे चलने वाले एजेंट्स से कहीं ज़्यादा बार सही काम करते हैं।
Browser MCP toolkit जो आपके agents को मिलता है
Browser access वाला हर AI agent इन tools के साथ boot होता है। ये standard MCP के ज़रिए expose होते हैं, इसलिए कोई भी compatible CLI इन्हें देखता है: Claude Code, Codex CLI, OpenCode, Antigravity CLI, Aider, Grok Build, Mistral Vibe, Kimi Code।
browser_navigate
एम्बेडेड ब्राउज़र में कोई URL खोलें। स्मार्ट URL हैंडलिंग: localhost:3000 'cannot open application' डायलॉग दिखाने के बजाय http://localhost:3000 बन जाता है। लोड होने के बाद फ़ाइनल URL और पेज का स्क्रीनशॉट लौटाता है।
browser_click
किसी एलिमेंट पर सेलेक्टर से या दिखने वाले टेक्स्ट से क्लिक करें। असली नेटिव click इवेंट, कोई JavaScript डिस्पैच नहीं। क्लिक के बाद का स्क्रीनशॉट लौटाता है, ताकि एजेंट अपनी कार्रवाई का नतीजा देख सके।
browser_type
एक input या textarea में text type करें। Keyboard shortcuts और submit support करता है। Real key events, page के onChange handlers fire होते हैं। Typing के बाद screenshot return करता है।
browser_screenshot
मौजूदा व्यूपोर्ट को PNG के रूप में कैप्चर करें। विज़ुअल रिग्रेशन जाँच, डिज़ाइन QA, पहले-बाद की तुलना, या किसी बग की स्थिति बाकी टीम के साथ साझा करने के लिए उपयोगी।
browser_evaluate
Page के main world में एक JavaScript expression run करें। Serialized result वापस पाएँ। Agents इसका इस्तेमाल page state पढ़ने, DOM query करने, Redux store inspect करने, या ऐसा action trigger करने के लिए करते हैं जिसका कोई visible button नहीं है।
browser_wait_for
एक element के दिखने का, URL बदलने का, network request finish होने का, या arbitrary JavaScript के true return करने का इंतज़ार करें। Classic 'agent बहुत तेज़ click करता है' race को avoid करता है।
browser_get_state
मौजूदा URL, टाइटल, व्यूपोर्ट, स्क्रॉल पोज़िशन और पेज के एक्सेसिबल एलिमेंट्स का स्ट्रक्चर्ड स्नैपशॉट पढ़ें। जब एजेंट को अपनी अगली कार्रवाई तय करनी हो, तब यही उसका मुख्य इनपुट होता है।
browser_get_logs
कंसोल बफ़र (log, warn, error) निकालें। एजेंट वही React वॉर्निंग, हाइड्रेशन एरर, नेटवर्क फ़ेल्योर और रनटाइम एक्सेप्शन देख सकता है जो आप DevTools में देखते। बग रिपोर्ट अब 'कंसोल का एरर यह रहा' बन जाती है।
browser_go_back / forward / reload
Standard browser navigation, scriptable। Agents इसका इस्तेमाल तब करते हैं जब flow गलत जाए तो backtrack करने के लिए, या Vite, Next.js या Expo Metro से hot reload के बाद page को re-test करने के लिए।
Agents browser के साथ वाकई क्या करते हैं
QA Engineer role और Agent Teams के साथ आज आप जो real workflows बना सकते हैं।
हर handoff पर end-to-end smoke test
Dev से QA तक की एक टीम जोड़ें। QA एजेंट आपके localhost dev सर्वर पर जाता है, अहम रास्तों (साइनअप, चेकआउट, डैशबोर्ड) पर क्लिक करता है, नतीजे का स्क्रीनशॉट लेता है, और तभी मंज़ूरी देता है जब कहीं कुछ न टूटे। किसी इंसान के पेज खोलने से पहले ही रिग्रेशन पकड़ें।
Visual regression QA
UI changes पर before-and-after screenshots। Agent पिछले commit पर page load करता है, screenshot लेता है, branch switch करता है, screenshot लेता है, Claude से compare करने को कहता है। Loop में Percy या Chromatic के बिना सस्ता visual diff QA।
Console error hunting
एजेंट ऐप में नेविगेट करता है, browser_get_logs कॉल करता है, और React हाइड्रेशन वॉर्निंग, useEffect वॉर्निंग, नेटवर्क 404, CORS एरर तथा डिप्रिकेशन नोटिस ढूँढ निकालता है। टीम हैंडऑफ़ पेलोड में उन्हें जोखिमों की सूची के रूप में रिपोर्ट करता है, और अगला Dev एजेंट उन्हें ठीक करता है।
Form validation testing
एजेंट फ़ॉर्म को सही डेटा से भरता है, खाली फ़ील्ड्स के साथ भरता है, और एज केस (XSS स्ट्रिंग्स, बहुत लंबे इनपुट, non-ASCII) के साथ भी। वैलिडेशन मैसेज, नेटवर्क रिक्वेस्ट और रीडायरेक्ट जाँचता है। असली फ़ॉर्म QA, यूनिट टेस्ट नहीं।
Accessibility audit
एजेंट पूरे पेज पर घूमता है, browser_get_state और browser_evaluate के ज़रिए एक्सेसिबिलिटी ट्री क्वेरी करता है, alt टेक्स्ट, ARIA एट्रिब्यूट्स, फ़ोकस मैनेजमेंट और कीबोर्ड नेविगेशन जाँचता है। समस्याओं की रिपोर्ट स्क्रीनशॉट के साथ देता है।
Figma के against design QA
इसे Figma to AI agents फ़ीचर के साथ मिलाएँ। एजेंट Figma फ़्रेम लोड करता है, स्क्रीनशॉट लेता है, फिर localhost पेज लोड करता है, स्क्रीनशॉट लेता है, और स्पेसिंग, फ़ॉन्ट, रंग तथा अलाइनमेंट की तुलना करता है। फिर बेमेल चीज़ों की सूची दर्ज करता है।
Live preview tunnel verification
AgentsRoom localhost tunnel के साथ pair करें। Agent public HTTPS preview URL (localhost नहीं) पर navigate करता है, verify करता है कि site outside world से reachable है, screenshot लेता है, और confirm करता है कि एक stakeholder वाकई link खोल सकता है।
एक public backlog ticket से customer bug reproduce करें
Public backlog ticket एक URL और reproduce करने के steps के साथ आता है। QA agent URL खोलता है, steps follow करता है, console error capture करता है, screenshot attach करता है, clean repro के साथ Dev को handoff करता है। 'reproduce नहीं कर सकता' loops नहीं।
किसी एलिमेंट पर इशारा करें और सीधे एजेंट को भेजें
ब्राउज़र को चलाना तो आधी कहानी है। कभी-कभी समस्या आप ही पकड़ते हैं: एक टेढ़ा बटन, गलत टेक्स्ट वाला लेबल, मोबाइल पर टूटने वाला कार्ड। शब्दों में बताने के बजाय, आप उस पर इशारा करते हैं। बिल्ट-इन ब्राउज़र में एक पॉइंट मोड है: पेज पर किसी भी एलिमेंट पर क्लिक करें और AgentsRoom लाइव DOM से उसका सटीक CSS सेलेक्टर पकड़ लेता है।
एक छोटा नोट जोड़ें, जैसे «यह स्पेसिंग कम करें» या «यहाँ रंग गलत है», और इशारा किया गया एलिमेंट आपके नोट के साथ सक्रिय एजेंट को एक सटीक, स्पष्ट बदलाव अनुरोध के रूप में भेज दिया जाता है। अब «बाएँ से तीसरा कार्ड» कहने की ज़रूरत नहीं: एजेंट को सेलेक्टर, आसपास का संदर्भ और आपका इरादा एक ही बार में मिल जाता है।
AgentsRoom ब्राउज़र में पॉइंट मोड: किसी एलिमेंट पर क्लिक करें, नोट जोड़ें, और सटीक सेलेक्टर आपके नोट के साथ एजेंट को इशारा किए गए बदलाव के रूप में भेज दिया जाता है।
पॉइंट मोड चालू करें
अपने ऐप पर बिल्ट-इन ब्राउज़र खोलें और पॉइंट बटन दबाएँ। माउस ले जाने पर हर एलिमेंट हाइलाइट होता है।
एलिमेंट पर क्लिक करें
जिस बटन, टेक्स्ट ब्लॉक या कार्ड को बदलना है उस पर क्लिक करें। AgentsRoom उसे लॉक करता है और लाइव DOM से उसका सटीक CSS सेलेक्टर पढ़ता है।
नोट जोड़ें और भेजें
क्या बदलना है यह टाइप करें और पुष्टि करें। सेलेक्टर, आसपास का संदर्भ और आपका नोट सक्रिय एजेंट को इशारा किए गए बदलाव के रूप में सौंप दिए जाते हैं।
एक agent को browser कैसे मिलता है
अपने room में Browser tab खोलें
अपने project room में, right panel तीन tabs expose करता है: Files, Changes, Browser। Browser पर click करें। Panel चौड़ा होता है, side bar collapse होता है, और एक असली Chromium view दिखाई देता है। एक URL type करें या project history से चुनें।
Agent पर 'Browser access' tick करें
Edit Agent modal खोलें, Capabilities expand करें, Browser access tick करें। AgentsRoom आपके project के .mcp.json में agentsroom-browser entry merge करता है और agent अगले start पर browser tools देखेगा।
<project>/.mcp.jsonAgent browser MCP के साथ boot होता है
Agent spawn पर, Claude (या Codex, Antigravity, आदि) agentsroom-browser MCP server initialize करता है, उसके tools list करता है (browser_navigate, browser_click, browser_type, browser_screenshot, browser_evaluate, browser_wait_for, browser_get_state, browser_get_logs, browser_go_back, browser_go_forward, browser_reload), और अब से browser चला सकता है।
Agent browser इस्तेमाल करता है
Agent navigate करता है, click करता है, type करता है, screenshots लेता है, console पढ़ता है। हर action loopback WebSocket bridge (127.0.0.1, OS-assigned port, 32-byte hex token, desktop app के हर boot पर regenerated) से होकर जाता है। हर page-changing action के बाद, एक screenshot inline return होता है ताकि agent visually अपनी move verify करे।
Localhost या आपके tunnel पर auto-target
अगर कोई localhost टनल चल रही है, तो पहला नेविगेशन उसी टनल URL पर पहुँचता है। नहीं तो पहले मिले dev सर्वर पर। वह भी नहीं तो https://localhost:3000 पर। Dev Terminals के साथ मिलाकर, एजेंट सचमुच dev सर्वर शुरू करता है, फिर उसे ब्राउज़र में खोलता है, फिर टेस्ट करता है।
Verify, screenshot, handoff
Agent Teams में wired होने पर, QA node अपने scenarios run करता है, screenshots capture करता है, handoff payload में flags.qaPassed set करता है। अगला agent verdict inherit करता है। Pass PM पर जाता है, fail test hints के साथ Dev पर loop back होता है।
Hood के नीचे
Curious लोगों के लिए। Browser automation stack purpose से छोटा है।
हर प्रोजेक्ट के पास एक Chromium WebContentsView होता है (आधुनिक Electron API, डिप्रिकेटेड BrowserView नहीं), जो React रेंडरर से स्ट्रीम हुए bounds पर मुख्य विंडो के ऊपर रखा जाता है। प्रति-प्रोजेक्ट सेशन पार्टिशन कुकीज़, localStorage और ऑथेंटिकेशन को प्रोजेक्ट्स के बीच अलग-अलग रखता है। डिफ़ॉल्ट ऑफ़स्क्रीन bounds की वजह से एजेंट्स ब्राउज़र टूल्स तब भी कॉल कर सकते हैं जब आपने Browser टैब खोला ही न हो, और स्क्रीनशॉट पर 5 सेकंड का टाइमआउट अटकने से बचाता है।
एक lightweight WebSocket server (browser-bridge.ts) OS द्वारा chosen एक loopback port पर चलता है, सिर्फ 127.0.0.1 से bound। Authentication हर desktop boot पर regenerated 32-byte hex token का इस्तेमाल करता है। Bridge file ~/.agentsroom/browser-bridge.json current port, token और PID रखता है, हर boot पर atomically rewritten, ताकि MCP subprocess हमेशा automatic retry के साथ fresh credentials उठाए।
MCP server खुद browser-mcp-server.cjs है, एक zero-dependency Node script जो stdio पर MCP 2024-11-05 protocol implement करता है (initialize, tools/list, tools/call)। यह WebSocket bridge से एक hand-rolled WebSocket client (कोई ws नहीं, कोई @modelcontextprotocol/sdk नहीं) के ज़रिए JSON-RPC बोलता है। Tiny, fast, audit करना आसान। Desktop app में extraResources file के रूप में bundled, ताकि हर install इसके साथ ready ship हो।
Native browser support (MCP से परे एक first-class browser feature) AgentsRoom roadmap पर है। उसके परे, long-term plan में additional MCPs शामिल हैं ताकि agents non-web targets भी चला सकें: mobile apps के लिए एक React Native MCP और desktop apps के लिए एक Electron MCP। वही idea, वही UX: agent सिर्फ code नहीं लिखता, वह वाकई running app exercise करता है।
FAQ
यह Playwright MCP या Puppeteer-based browser tools से कैसे अलग है?
Playwright और Puppeteer-based MCPs हर session पर एक fresh headless browser spawn करते हैं। यह stateless tasks के लिए ठीक है, लेकिन यह calls के बीच cookies, localStorage और auth खो देता है, और human नहीं देख सकता agent क्या कर रहा है। AgentsRoom Browser वही browser है जो human app के अंदर इस्तेमाल करता है, persistent per-project session के साथ, real time में user को visible। Agent एक window चलाता है जिसे आप देख सकते हैं और किसी भी समय override कर सकते हैं। यह एक ज़्यादा honest, ज़्यादा debuggable browser automation है।
क्या यह सभी AI providers के साथ काम करता है, या सिर्फ Claude Code?
यह AgentsRoom के सपोर्ट किए हर प्रोवाइडर के साथ काम करता है: Claude Code, Codex CLI, OpenCode, Antigravity CLI, Aider, Grok Build, Mistral Vibe और Kimi Code। ब्राउज़र टूल्स स्टैंडर्ड Model Context Protocol के ज़रिए उपलब्ध होते हैं, जिसे ये सभी CLI .mcp.json से पढ़ते हैं। एजेंट को कभी पता नहीं चलता कि वह AgentsRoom में है: उसे बस MCP टूल्स का एक सेट दिखता है और वह उन्हें किसी भी दूसरे टूल की तरह इस्तेमाल करता है।
क्या agent एक remote site चला सकता है, या सिर्फ localhost?
दोनों। कोई भी URL type करें और जाएँ। Localhost (और host:port forms) smart-detected हैं, http:// से prefixed, और सीधे खोले जाते हैं। Public sites किसी भी normal browser की तरह काम करती हैं, per project preserved cookies और login state के साथ। AgentsRoom localhost tunnel के साथ combined, agent आपके local dev server को एक public HTTPS URL के ज़रिए भी चला सकता है, जो cross-network और mobile QA के लिए useful है।
क्या browser MCP secure है? इसे abuse होने से क्या रोकता है?
ब्रिज सिर्फ़ 127.0.0.1 पर बाइंड होता है, कभी 0.0.0.0 पर नहीं। पोर्ट OS तय करता है (स्कैन में आसानी से पकड़ में आने वाला कोई फ़िक्स्ड पोर्ट नहीं)। हर कनेक्शन पर 32-बाइट hex टोकन ज़रूरी है, जो डेस्कटॉप के हर बूट पर नया बनता है। MCP सबप्रोसेस को क्रेडेंशियल सिर्फ़ env वेरिएबल्स से मिलते हैं, कभी किसी कमिट की गई फ़ाइल में नहीं। ब्राउज़र ऐक्सेस हर एजेंट के लिए Edit Agent मोडल में ऑप्ट-इन है। आप उसे हटा देते हैं तो .mcp.json की एंट्री हट जाती है और एजेंट फिर वे टूल्स इस्तेमाल नहीं कर सकता।
क्या एजेंट ब्राउज़र कंसोल (एरर, वॉर्निंग, नेटवर्क) देखता है?
हाँ, browser_get_logs के ज़रिए। बफ़र पेज की मुख्य वर्ल्ड से console.log, console.warn और console.error मैसेज रखता है। कई असली बग (React हाइड्रेशन एरर, useEffect वॉर्निंग, CORS फ़ेल्योर) सिर्फ़ कंसोल में दिखते हैं, यूनिट टेस्ट में कभी नहीं, इसलिए QA एजेंट के लिए यह सबसे काम के टूल्स में से एक साबित होता है।
Agent को return किए गए screenshots का क्या होता है? क्या वे बहुत सारे tokens cost करते हैं?
हर page-changing action के बाद, tool response में 1.6 MB पर capped एक base64 PNG screenshot append होता है। उससे ऊपर, उसकी जगह एक text marker भेजा जाता है। Screenshots reliability के लिए critical हैं (agent जो screen देखता है कहीं कम गलतियाँ करता है), इसलिए trade-off worth है। अगर आप budget reasons के लिए screenshots disable करना चाहते हैं, plain browser_evaluate calls सिर्फ text return करते हैं।
क्या agent एक login form भर सकता है? अपनी session persist कर सकता है?
हाँ। Cookies और localStorage persist:agentsroom-browser-<projectId> session partition के तहत हर project के लिए persisted हैं। Agent एक बार browser_type और browser_click से log in कर सकता है, और बाकी run में logged in रह सकता है। जब आप project switch करते हैं, session बदल जाती है, इसलिए credentials projects में कभी leak नहीं होते।
क्या agent break हो जाएगा अगर dev server नहीं चल रहा?
यह URL पर navigate करेगा और एक Chromium error page देखेगा। यह उस error को browser_get_state और browser_get_logs के ज़रिए पढ़ सकता है और तदनुसार react कर सकता है: आपसे server start करने को कहे, या उसे start करने के लिए एक Dev Terminals command call करे। Agent Teams और Dev Terminals के साथ, आप एक workflow wire कर सकते हैं जो server start करता है, इंतज़ार करता है, फिर browser खोलता है, सब कुछ बिना human intervention के।
क्या mobile apps और desktop apps भी supported हैं?
Web आज ship हो रहा है, embedded Chromium और AgentsRoom Browser MCP के ज़रिए। Roadmap में first-class browser feature के रूप में native AgentsRoom Browser शामिल है। उससे परे, additional MCP servers planned हैं: एक React Native MCP ताकि agents iOS और Android Expo bundles चला सकें, और एक Electron MCP ताकि agents desktop apps चला सकें जो web नहीं हैं। वही agent logic, non-web targets पर लागू।
क्या human agent को pause करके browser take over कर सकता है?
हाँ। Browser वही Chromium view है जो human इस्तेमाल करता है। किसी भी moment पर, Browser panel में click करें और आप control में हैं। एक बार जब आप interact करना बंद कर देते हैं, agent अपने tool calls resume कर सकता है। 'agent-locked browser' का कोई concept नहीं है, यह एक shared surface है, ठीक pair-programming session की तरह।
के बारे में : एजेंट डेलिगेशन
ब्राउज़र को आपके dev एजेंट के बजाय एक सस्ते QA एजेंट को चलाने दें
Browser MCP तब सबसे अच्छा चमकता है जब dev एजेंट उसे सीधे न चलाए। एजेंट डेलिगेशन एक run_qa_test MCP कॉल के ज़रिए ब्राउज़र टेस्ट को एक अलग, सस्ते QA एजेंट को रूट करता है। आपका Opus या Codex कोड पर केंद्रित रहता है, QA एजेंट छोटे मॉडल पर क्लिक करता है, वर्डिक्ट एक लाइन में वापस आता है।
एजेंट डेलिगेशन पेज पढ़ेंअपने agents को असली browser eyes दें
AgentsRoom में किसी भी agent पर Browser access tick करें। Browser MCP automatic boot होता है। आपका QA agent आखिरकार वह test करता है जो वह ship करता है।
कंपेनियन ऐप: चलते-फिरते अपने एजेंट्स मॉनिटर करें
Claude, Codex, Antigravity CLI या किसी अन्य AI प्रदाता का उपयोग करें।
बग और अनुरोध सीधे अपने सार्वजनिक बैकलॉग में भेजें।
AgentsRoom को कार्य करते देखें।