Hướng dẫn

Tự động hoá trình duyệt và Computer Use

Cho agent dùng trình duyệt hoặc ứng dụng desktop của bạn.

Hướng dẫn này hiện chỉ có bản tiếng Anh.

In-app browser

Ask an agent to inspect a website, test a flow, or verify a UI change. VC prioritizes the in-app browser, where you can watch the same page and take over. The agent opens a preview when needed, inspects the page, performs the requested actions, and checks the result. Project Agent browser access settings still apply.

This workflow is shared by VC’s integrated Codex, Claude, Cursor, Grok, managed OpenCode, Antigravity, and Devin sessions (Devin on macOS and Linux), regardless of the selected model. Available operations depend on the connected browser host. Web Preview can also host these operations for a remote project’s localhost page. Keep the VC client and its preview tab open and allow Agent browser access for the project. Web snapshots contain page structure and element references without a screenshot. Public websites embedded directly and pages in limited mode do not provide this automation runtime.

For models without image support, the agent can request text-only results and use semantic controls: includeImage: false on preview_snapshot, or on agent_browser_use calls starting with open.

When an agent delegates a browser check to a child thread, give the child a URL or dev server and acceptance criteria, and ask for the steps performed, observed results, and screenshots or a recording as evidence. Each agent has its own current tab and can use up to 3 tabs in a browser. Agents cannot control or close tabs belonging to another agent, even in the same thread or shared project browser. Ask the agent to close one of its tabs before opening a fourth. Agents should exchange URLs and evidence rather than assume they share a tab.

If the connected host cannot perform an operation, the agent can use Agent Browser Use for that part when supported and enabled on the environment. Web and mobile clients can use an attached desktop preview host. Keep both the server and desktop app updated; older preview hosts cannot provide independent agent tabs.

Enable isolated browser or computer control

Open Settings → Integrations on web or desktop and select the environment’s controls. Both features are off until enabled. Start a new agent session after enabling them. Full access does not enable either feature. On mobile, the same switches appear in Settings under each environment’s name; they control the environment’s computer, not the phone.

Agent Browser Use

Enable Agent Browser Use to let an agent open an isolated browser on the selected environment. Chrome must be installed there; on Windows, VC uses Microsoft Edge when Chrome is missing. Use Browser executable for another Chrome or Chromium installation. Project browser-access settings continue to apply.

Ask the agent to use agent_browser_use to open a URL, inspect the page, fill fields and click controls. It receives accessibility text and screenshots after actions by default. With includeImage: false, it receives page text and element references without capturing an image; an explicit screenshot still returns an image. This works with web, desktop and mobile clients even without an attached desktop preview host. The environment browser runs in the background; it does not import your personal cookies or browser profile. Tabs are private to the agent session and close after 30 minutes of inactivity or server shutdown. The collaborative in-app browser remains the default for browser work.

Use your existing Chrome or Edge browser

Enable Agent Browser Use, then give the agent the browser’s remote debugging (CDP) address and ask it to connect. Remote debugging must already be enabled; a normal browser window alone is not enough. Supply an HTTP(S) address such as http://127.0.0.1:9222 or the browser’s WebSocket address. The address must be reachable from the selected VC environment; when VC runs remotely, its localhost is not your computer. Keep debugging access restricted to trusted connections.

The agent works in background tabs that it opens itself, using your existing sign-ins, so you can keep using the same browser. Like the in-app and isolated browsers, this does not move your physical pointer or send keyboard input to other apps, and it does not switch the tab you have selected.

Your own tabs are left alone unless the task needs one. Ask for it explicitly, for example “finish the form in the tab I have open”. The agent then clicks, types and scrolls in that page, which moves its focused field and scroll position; avoid typing there until it finishes.

Ask the agent to disconnect when finished. Disconnecting, session expiry and server shutdown leave your browser and tabs open. Asking it to close a tab does close that tab. Disconnect before switching to a different browser.

Open a project’s browser

In the desktop app, the project’s ⋯ → Browser menu in Workspaces opens the project’s workspace with the in-app browser in the side panel, where agents work through the collaborative browser above.

On web, the same menu opens a window onto a browser running on the environment. Enter a URL on that environment, then use the page image to click, the text field to type into the focused input, and the scroll controls. The image updates after each action; Refresh follows the browser’s current tab, including changes made by an agent.

Enable Agent Browser Use for the environment in Settings → Integrations first. In the project’s Browser window, enable Agent Browser Use to grant shared control. Agents use agent_browser_use with sharedProject: true; VC derives the project from their authenticated thread. They cannot select another project’s browser by supplying an ID. Existing project browser-access rules still apply.

Manual navigation, clicks or typing return control to you and block queued agent actions that have not started. Re-enable shared control when you want the agent to continue. Closing the window leaves its browser available; Close tab closes the selected tab. Sessions expire after 30 minutes of inactivity or server shutdown.

Computer Use

Computer Use supports macOS 14 or later, Windows, and Linux. On macOS it runs the bundled VC Computer Use helper app; on Windows it runs the bundled runtime.ps1 PowerShell helper over UI Automation; on Linux it runs a bundled Python helper over AT-SPI and needs python3 with GI bindings (python3-gi, gir1.2-atspi-2.0, at-spi2-core) plus an active desktop session. Enable Computer Use, or configure an absolute helper path on the environment first. On macOS grant the helper Accessibility and Screen Recording access in System Settings → Privacy & Security; on Windows it needs an interactive desktop session. VC does not grant OS permissions for you.

Ask the agent to inspect the app before acting. Computer Use works in the background on all three platforms: VC does not move your pointer, synthesize keyboard input, use your clipboard, or bring target windows forward. It fills supported fields and operates controls through accessibility APIs. If an operation requires shared desktop input, VC reports it as unsupported. Coordinate clicks, dragging, and general keyboard shortcuts are unavailable. macOS can replace text and select all through Accessibility; Windows rejects WPF controls that activate their window, and Linux scrolling is unavailable. On Windows, apps running as administrator can only be controlled when VC also runs as administrator.

For browser work while you continue using your computer, ask for the isolated agent browser or an agent-created background tab in a connected browser. For the integrated VC browser, ask for a separate background tab. These controls still change the target application’s data, so avoid sharing the exact tab or app field you are editing.

Settings → Skills also lists a managed vc-computer-use skill. Installing it writes a short how-to-use computer_use skill into the environment’s agent skill directories (the cross-agent .agents/skills directory plus any provider directories that already exist), so agents that discover skills learn the inspect-before-act workflow. Removing it deletes only the managed copies.

Turning a feature off closes its active automation sessions. Agents in VC terminals receive an in-app browser connection automatically, bound to their workspace. Ask the agent to use VC’s integrated browser; no token setup is needed. Codex, Claude, OpenCode, Command Code and Devin launched by VC load the tools directly. CLIs started by hand from a shell, and other CLIs, can use the same tools through VC’s terminal bridge, described in the managed vc-agent-browser skill. Restart an existing terminal to receive the connection. Closing or restarting a terminal revokes its old connection without affecting other agents. Keep a VC web or desktop client with the preview tab open to use the collaborative browser. Agents launched outside VC can use an external agent token (below).

External agents

Agents VC did not start itself — a CLI in a terminal, an editor, or another harness — can use the same browser and automation tools through an external agent token. Open Settings → Integrations → External agents, pick the thread whose preview panel the agent should drive, choose capabilities, and create the token. The dialog shows the MCP config once; paste it into the other client’s MCP configuration and keep that thread open in VC while the agent works.

Externally managed OpenCode servers also need this setup; VC does not change the MCP configuration of a server you run yourself.

Tokens grant only the capabilities you select, never the workspace tools:

  • Integrated browser drives the preview panel tab in the bound thread.
  • Headless / project browser uses agent_browser_use; enable Agent Browser Use first.
  • Computer Use uses computer_use; enable Computer Use first.

Capabilities are checked against the live switches on every request, so turning agent browser access off takes the tools away from an already-configured client. Revoking a token cuts access immediately. Tokens can expire, and the raw bearer is only shown when it is created.

Workspace tools

Provider sessions with VC’s MCP connection also get data tools that do not need either automation switch:

  • tasks_* keeps a shared task board with priorities, dependencies, comments, and approval gates. tasks_next claims the next ready task for the session; tasks_wait waits on an approval gate without ever approving it itself. Archive tasks to remove them from active lists while keeping their history and links. The Tasks tool’s Archived view lets you restore them or permanently delete them after confirmation. Archived dependencies still block unfinished work.
  • database_* describes, queries, and previews tables on SQLite, PostgreSQL, and MySQL connections. Add connections with database_manage_connections.
  • http_* sends requests and runs saved requests with environment variables. Save requests and environments with http_manage.
  • delegate_task, task_status, and task_cancel hand bounded work to child threads and follow or stop them; orchestrator_capabilities lists the models a child can use. See Delegate work to child threads.

Connections, saved requests, and tasks are stored as JSON in the environment’s state directory, so they travel with the environment and are readable and editable outside VC. Ask the agent which tool description it has for exact arguments.