आपके agents एक असली browser चलाते हैं।
नकली नहीं।
AgentsRoom हर project में एक असली Chromium browser embed करता है, और एक AgentsRoom Browser MCP server ship करता है जो आपके AI agents को इसे control करने देता है। आपका QA agent localhost site खोलता है, buttons click करता है, forms भरता है, screenshots लेता है, console पढ़ता है, और 'done' कहने से पहले verify करता है कि feature वाकई काम कर रहा है। Claude Code, Codex, OpenCode, Gemini CLI और Aider के लिए end-to-end browser automation, zero Playwright config के साथ।
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 एक में दो चीज़ें हैं। पहला, हर project room में embedded एक असली Chromium browser, URL bar, back/forward, reload, history, clipboard में screenshot, default browser में open, persistent cookies और हर project के लिए localStorage के साथ। दूसरा, एक AgentsRoom Browser MCP server (agentsroom-browser) जो उस browser को आपके AI agents को Model Context Protocol के ज़रिए expose करता है। Agent को एक clean, scriptable interface मिलता है: navigate, click, type, screenshot, JavaScript evaluate, element का इंतज़ार, page state पाएँ, console logs पाएँ, 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 panel: URL bar, history, screenshot, और AI agents के लिए navigate, click, type और verify करने के लिए full MCP control surface।
एक असली browser, Playwright stub नहीं
ज़्यादातर AI agent demos जो browser automation की बात करते हैं हर tool call पर एक headless Playwright instance spawn करते हैं। यह benchmarks के लिए काम करता है लेकिन real life में painful है: आप नहीं देख सकते agent क्या कर रहा है, हर navigation Chromium को respawn करता है, cookies खो जाते हैं, localStorage खाली है, आपका dev server सोचता है हर visit एक brand new session है। AgentsRoom अलग angle लेता है। Browser आपके project room में पहले से खुला है (आप इसे खुद इस्तेमाल करते हैं, normal browser की तरह), और agent उस browser को चलाता है। Sessions, cookies, localStorage, login state, सब preserved।
Agent से हर click और type Electron के WebContentsView के ज़रिए एक real native dispatch trigger करता है, proper key events, mouse events और DOM mutations के साथ। Screenshots actual rendered page से capture किए गए असली PNGs हैं (कोई DOM-to-image hack नहीं)। Console logs buffer होते हैं और queryable हैं, warnings और errors सहित। Agent वही देखता है जो आप देखते अगर DevTools खुले होते: real performance, real network behavior, real CORS, real auth।
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 layer intentionally छोटी और dependency-free है। browser-mcp-server.cjs subprocess MCP 2024-11-05 protocol stdio पर बोलता है (initialize, tools/list, tools/call) और इसे loopback WebSocket bridge पर JSON-RPC calls में translate करता है। एक heavy SDK-based server की तुलना में, यह fast रहता है (पहला tool call sub-100ms) और debug करना आसान। हर action के बाद जो page बदलता है (click, type, navigate, reload, back, forward), response में 1.6 MB पर capped एक base64 PNG screenshot शामिल होता है ताकि agent हमेशा देखे कि उसने अभी क्या किया का result है। यह सबसे बड़ी reliability win निकली: agents जो screen देखते हैं वे हमेशा hope करने वाले agents से कहीं ज़्यादा सही काम करते हैं।
Browser MCP toolkit जो आपके agents को मिलता है
Browser access वाला हर AI agent इन tools के साथ boot होता है। ये standard MCP के ज़रिए expose होते हैं, इसलिए कोई भी compatible CLI इन्हें देखता है: Claude Code, Codex CLI, OpenCode, Gemini CLI, Aider।
browser_navigate
Embedded browser में एक URL खोलें। Smart URL handling: localhost:3000 'cannot open application' dialog trigger करने के बजाय http://localhost:3000 बन जाता है। Final URL और load के बाद page का screenshot return करता है।
browser_click
Selector या visible text द्वारा एक element पर click करें। Real native click event, JavaScript dispatch नहीं। Post-click screenshot return करता है ताकि agent अपने action का result देखे।
browser_type
एक input या textarea में text type करें। Keyboard shortcuts और submit support करता है। Real key events, page के onChange handlers fire होते हैं। Typing के बाद screenshot return करता है।
browser_screenshot
Current viewport को PNG के रूप में capture करें। Visual regression checks, design QA, before-and-after comparisons के लिए, या team के बाकी लोगों के साथ bug की state share करने के लिए useful।
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
Current URL, title, viewport, scroll position, और page के accessible elements का structured snapshot पढ़ें। Agent का primary input जब उसे अपना next action plan करना हो।
browser_get_logs
Console buffer (log, warn, error) pull करें। Agent वही React warnings, hydration errors, network failures और runtime exceptions देख सकता है जो आप DevTools में देखते। Bug reports बन जाते हैं 'console से error यहाँ है'।
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 to QA team wire करें। QA agent आपके localhost dev server पर navigate करता है, critical paths (signup, checkout, dashboard) पर click करता है, result screenshot करता है, और sign off करता है केवल अगर कुछ throw नहीं हुआ। Human के page खोलने से पहले regressions पकड़ें।
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
Agent app navigate करता है, browser_get_logs call करता है, React hydration warnings, useEffect warnings, network 404s, CORS errors, deprecation notices ढूँढता है। Team handoff payload में risks की list के रूप में report करता है, अगला Dev agent उन्हें fix करता है।
Form validation testing
Agent form को valid data, empty fields, edge cases (XSS strings, बहुत लंबे inputs, non-ASCII) से भरता है। Validation messages, network requests, redirects verify करता है। Real form QA, unit tests नहीं।
Accessibility audit
Agent page walk करता है, browser_get_state और browser_evaluate के ज़रिए accessibility tree query करता है, alt texts, ARIA attributes, focus management, keyboard navigation check करता है। Screenshots के साथ issues report करता है।
Figma के against design QA
Figma to AI agents feature के साथ combine करें। Agent Figma frame load करता है, screenshot लेता है, localhost page load करता है, screenshot लेता है, spacings, fonts, colors, alignments compare करता है। Mismatches की list file करता है।
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 नहीं।
एक 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, Gemini, आदि) 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 tunnel चल रहा है, पहला navigation tunnel URL पर land होता है। नहीं तो, पहला detected dev server। नहीं तो, https://localhost:3000। Dev Terminals के साथ combined, agent literally dev server start करता है, फिर browser में खोलता है, फिर test करता है।
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 से छोटा है।
हर project में एक Chromium WebContentsView है (modern Electron API, deprecated BrowserView नहीं), main window पर React renderer से streamed bounds पर overlaid। Per-project session partition cookies, localStorage और authentication को projects के बीच isolated रखता है। Default offscreen bounds agents को browser tools call करने देते हैं human के Browser tab खोलने से पहले भी, screenshots पर 5-second timeout के साथ ताकि hangs avoid हों।
एक 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?
यह हर provider के साथ काम करता है जो AgentsRoom support करता है: Claude Code, Codex CLI, OpenCode, Gemini CLI और Aider। Browser tools standard Model Context Protocol के ज़रिए expose होते हैं, जिसे ये सारे CLIs .mcp.json से पढ़ते हैं। Agent कभी नहीं जानता कि वह AgentsRoom में है, वह सिर्फ MCP tools का एक set देखता है और जैसे किसी और tool को इस्तेमाल करता वैसे इन्हें इस्तेमाल करता है।
क्या 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 होने से क्या रोकता है?
Bridge सिर्फ 127.0.0.1 से bind होता है, कभी 0.0.0.0 से नहीं। Port OS-assigned है (collision-prone scanning के लिए कोई fixed port नहीं)। हर connection पर 32-byte hex token required है, हर desktop boot पर regenerated। MCP subprocess credentials सिर्फ env vars के ज़रिए receive करता है, कभी किसी committed file में नहीं। Browser access Edit Agent modal में हर agent के लिए opt-in है। अगर आप इसे remove करते हैं, .mcp.json entry remove हो जाती है और agent अब tools इस्तेमाल नहीं कर सकता।
क्या agent browser console (errors, warnings, network) देखता है?
हाँ, browser_get_logs के ज़रिए। Buffer page के main world से console.log, console.warn और console.error messages रखता है। बहुत सारे real bugs (React hydration errors, useEffect warnings, CORS failures) सिर्फ console में surface होते हैं, कभी unit tests में नहीं, इसलिए यह QA agent के लिए एक highest-signal tool निकलता है।
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 की तरह।
अपने agents को असली browser eyes दें
AgentsRoom में किसी भी agent पर Browser access tick करें। Browser MCP automatic boot होता है। आपका QA agent आखिरकार वह test करता है जो वह ship करता है।
कंपेनियन ऐप: चलते-फिरते अपने एजेंट्स मॉनिटर करें
Claude, Codex, OpenCode, Gemini CLI और Aider के साथ काम करता है
बग और अनुरोध सीधे अपने सार्वजनिक बैकलॉग में भेजें।