Amp brings Portals to local machines: see your dev server right in the thread

A familiar situation: the agent wrote a frontend and started a dev server, and now you have to open a terminal, hunt for the port and check what came out. If the agent is running on another machine, say a Mac at home while you sit in a cafe with a laptop, the task turns into a small quest. The Amp team at Sourcegraph is closing that gap: Portals, which used to live only in cloud orbs, now work on your own runner as well.

What changed

A Portal is a tab next to the thread that opens a web page created by the agent. Previously it was available when the agent worked in an orb. Now the same mechanism works on local machines: you ask Amp to start a dev server or build a site, and you open the result in the Portal tab in the thread. An important detail from the announcement is "no matter where you are." In other words, the runner can sit on one machine while you view the result from another.

Example from the announcement

The Amp developers showed a simple but telling case. In a thread on a macOS runner, the user asks for an overview page on Mac file system usage and to show it in a portal. The agent replies with a link to a Disk Usage portal, and a small web app opens alongside: 241 GB used out of 383 GB, a capacity bar split by category, and a donut chart showing that simulators and Xcode data take up 155 GB.

The value is not in the chart itself but in the loop: a question, code, a live page, and you immediately look at the result and refine the task. One-off internal dashboards that nobody would have built by hand before become almost free. Need to figure out what ate the disk, look at build metrics or check the layout? Ask the agent and you get a page, not a wall of text in chat.

How to enable it and who will see it

There are two ways. In the macOS app, open Settings › Runner and turn on Allow Portals. If you work from the terminal, start the runner with the command amp --no-tui --remote-control-portals.

By default, your runner's portals are available only to you. To show them to colleagues, start a shared runner with the --share flag or turn on Share With Workspace in the macOS app. Then any workspace member can open that runner's portals. Details are in the Amp documentation under Portals on Your Runner.

Limitations and practical takeaways

Some things to keep in mind. The option is off by default, and that is the right call: you decide whether to let the agent expose web pages from your machine. When you enable sharing for the whole workspace, remember that colleagues will see everything the agent shows in the portal. And on a local machine, anything can end up on the page: paths, project names, data from the file system. The disk report from the example is harmless on a personal Mac, but it should not be shown to an entire workspace without checking. The announcement gives no details on how access works or what technical limits portals have, so consult the documentation for the nuances.

The practical takeaway is simple. If you already use Amp with a local runner, turn on Allow Portals and try it on a task where you previously had to start a server by hand: a frontend preview, a dependency report, a log dashboard. If you work in a team, start with personal mode and enable --share only for runners that hold nothing sensitive.

And if you build agents yourself, take note of the idea. The ability to show a result as a live page rather than text in chat is a separate and badly underrated feature. It shortens the path from request to checking the result with your own eyes, and that is exactly the step where time usually gets lost.