Browser and simulator

Two of the right panel’s surfaces show the thing you’re building rather than its source: a Browser for web apps and an iOS Simulator for native ones. Both live in the right panel and both are things the agent can use, not just you.

Browser

⌘⇧W shows it. Each chat tab has its own browser, with browser tabs along the top: + opens one, and a link that asks for a new tab opens one too instead of leaving for your Mac’s default browser. The browser tabs and their addresses are remembered with the chat tab. Each workspace has its own cookies and storage, shared by its chat tabs and kept across restarts, so a signed-in dev server stays signed in — and a new workspace starts signed out. ⌘-click a URL in terminal output and it opens here. A page can’t hold you with a “Leave site?” warning: navigating away always goes ahead, so save a form before you leave it. A page that opens a popup — a sign-in with another provider, say — gets it as a separate window that shares the workspace’s cookies, so finishing there signs the page in.

The agent drives it

In Build mode the agent can use the browser itself: open a page, open and switch between browser tabs, read a page as an accessibility outline (embedded frames included), click and type by element, press keys, scroll at a human pace, go back and forward, run a script in the page, read the console, and take a screenshot to see how the page looks. That’s what lets it check a change it just made rather than assume it worked. In Ask and Plan mode it can only look: read the page you already have open, take a screenshot or a short recording of it, read its console, and list your browser tabs — never open, click, type, or run anything in it.

While it’s driving, an overlay on the page reads Agent is using this browser, with a Stop button; you get the page back when the turn ends. A page’s own dialogs (alert, confirm, prompt) go to the agent while it drives, and it answers them or stops to ask you. The agent can’t work inside a popup window: when a page opens one, it stops and asks you to finish there. It’s the same browser, so whatever you had signed into in that workspace is what the agent sees.

It doesn’t take over your panel. Ask for browser work and the Browser surface comes forward so you can watch. When the agent is checking its own change, it works in the background — Files, Changes, or whatever you had open stays put — and leaves a card in the chat that opens the page.

Whether it does this on its own is a setting — Settings › Chats › New chat defaults › Agent browser use: When it decides to (the default) lets the agent use the browser whenever it judges a check needs one; Only when asked waits for you. Either way you can ask it to at any time: “open localhost:3000 and check the sign-in form.”

Signing in with 1Password

The agent can sign in to a page with a login from your 1Password vault, and it never sees the password: Raven’s own 1Password connection types it. Set that up once in Settings › Integrations › 1Password (see Integrations) and import the logins Raven may use. In the browser’s address row, a key button — Logins the agent may use here — narrows that list for this workspace, grouped into This site and Everything else; a new workspace starts with All imported logins or No logins, whichever Settings › 1Password says. On a sign-in page the agent fills the login you’ve enabled, and asks which one if several fit.

Pictures in the reply

When the agent checks something, it can show you: a screenshot or a short clip of the page sits in its reply at that point, with its sentence as the caption. Click one to see it full size. The same goes for the simulator below, where a capture is drawn inside an iPhone frame. This works in every mode.

Simulator

⌘⇧S shows it, on any Mac. Raven runs the real iOS Simulator inside the panel: the device’s screen streams into the pane, keys you type go to the device (Esc hands your keyboard back; the device’s hardware keyboard is off, so the on-screen one appears as it would on a phone), and the pane reattaches to a running device when you come back to the workspace. Under the phone are Home, a screenshot button that copies to the clipboard, and the Build log.

One device per workspace

Every workspace gets its own simulator — created while a worktree workspace provisions, if the project has an Xcode project, or otherwise on first Launch — and removed when the workspace is archived or deleted. By default it’s the newest iPhone on the newest iOS runtime you have installed. The device line in the pane’s header is a menu of iPhones grouped by installed iOS; picking another replaces the device, and a device that already exists is deleted with its data after you confirm. Up to five stay booted at once; the least recently used is shut down to make room. Because the device belongs to the workspace, two workspaces can run two builds of the same app side by side.

Setup

The first launch runs a short checklist — Xcode, how to run your app, a device, and permission for Raven to keep the Simulator app itself out of your way — and stops on whatever’s missing. Set up with an agent opens a chat that fixes what the checks found; Set up manually starts with the run settings, then the checks. The permission step shows a one-time prompt with Open System Settings, and Skip if you’d rather not.

Run settings, behind the gear in the pane’s header, is where you say how the app builds and launches: accept the Xcode project Raven found, or give a Run command of your own. Nothing runs until one of them is saved with Save run command. That command is the project’s simulator run command, and the device is passed to it as $RAVEN_SIMULATOR_UDID.

Building and running

Launch Simulator boots the device and runs the command. Run in the pane’s header rebuilds and relaunches, with Building… and the elapsed time in the header, Stop beside it, and the build log in the pane. A failed build shows a card under the phone with the first error, the full log, and a way out: Debug in chat hands the failure and its log to a chat to fix, Run again retries, Change run config goes back to Run settings.

The header’s main Run button can be the same thing: set the project’s Run button to Simulator and pressing it (or ⌘R) opens this surface, boots the device and runs the command above. Left on Terminal command, it runs a shell command in the terminal instead, for a dev server or a script.

The agent drives it too

In Build mode the agent can launch the app — the same build, install, and launch the pane’s button does, or a rebuild after a change — read the screen as an accessibility outline, tap, swipe, type, press the hardware buttons and keys, take a screenshot, record a clip, and check the build’s state. So it can run the app and try its own change, the way it checks a web page. In Ask and Plan mode it can only look at what’s on screen. While it drives, the pane reads Agent is using this simulator with a Stop button, and your input waits until the turn ends; a card in the chat opens the pane, and the pane comes forward on its own only when you asked to watch. /set-up-simulator in the composer gets a workspace’s simulator running when setup needs fixing.