News · Agents and coding · News
AWS Bedrock AgentCore adds live preview URLs for coding agents
AWS has added a way to watch a web app while a coding agent builds it inside an Amazon Bedrock AgentCore session. The new Session endpoints give each session a temporary, authenticated URL that forwards browser requests to specific ports inside the agent's isolated microVM. For a coding agent that runs a Vite dev server, that means you can open the app, ask for a change, and see the page update when the agent saves files. No deployment step in between.
The sample from AWS walks through a setup with a chat pane on the left and the live website on the right. You ask the agent to switch the site to a dark theme, watch the steps stream in, and the browser updates without a refresh.
In one line: AWS Bedrock AgentCore runtime now gives each agent session a temporary authenticated URL that forwards browser traffic to approved ports, so a coding agent's dev server can push live changes to your browser.
How Session endpoints work
Each session gets its own Session endpoint. You set allowedPorts when you call CreateAgentRuntime: 1 to 5 entries, each a single port or a range within 8000 to 12000, excluding reserved platform ports. Allowing a port does not start a server. Your application must listen on it and bind to 0.0.0.0.
The URL arrives in the InvokeAgentRuntime response header X-Amzn-Bedrock-AgentCore-Runtime-Session-Endpoint-Url. SDKs expose it as sessionEndpointUrl. Every request is authenticated. For IAM based runtimes, each HTTP request, HTTP/2 stream, and WebSocket handshake carries a Signature Version 4 signature. The caller also needs bedrock-agentcore:InvokeAgentRuntimeProxy permission. For runtimes with an inbound JWT authorizer, each request carries a bearer token. Knowing the URL alone does not grant access.
The host name selects the port. Your client connects on port 443, and a prefix on the host name picks the port inside the session. The endpoint passes through HTTP/1.1, HTTP/2 including server-sent events and gRPC, and WebSocket connections.
A browser cannot add a SigV4 signature or bearer token to requests a page makes on its own. The Session endpoint client in the bedrock-agentcore SDK opens a local endpoint on your machine. Your browser opens localhost:8088, and the local endpoint adds your credentials before forwarding each request and WebSocket handshake.
Use a Session endpoint to see what your agent runs in its session, such as a web preview. It is scoped to one session and stops working when the session ends. To serve an app to end users, deploy to a hosting service such as AWS Amplify Hosting.
The sample setup
The AWS sample has four parts. A coding agent runs in the session on port 8080 and edits website files with four tools: list, read, write, and edit. The agent starts a Vite development server on port 8090. Vite serves the website and pushes each saved change to the browser over its hot-reload WebSocket.
On your machine, PreviewApp serves the preview page, sends your prompts to InvokeAgentRuntime, and opens a local endpoint for the website. The preview page loads the website from the local endpoint on localhost:8088. The local endpoint adds your credentials, forwards to the Session endpoint, and the Session endpoint checks the signature and allowedPorts before forwarding to Vite on port 8090.
When you send a prompt, PreviewApp sends it to InvokeAgentRuntime as a standard signed AWS API call. The runtime delivers it to the agent on port 8080. The agent calls Claude Haiku 5.5 in Amazon Bedrock to decide what to change, reads the site files, and saves the ones it changes. Vite serves those files and watches them. When a file saves, Vite pushes the change over the open WebSocket back through the Session endpoint and local endpoint. The page updates without a refresh.
The sample also reads the agent's /status route on port 8081 through the same Session endpoint. Port 8080 stays out of allowedPorts because InvokeAgentRuntime reaches the agent directly.
Why this matters for coding agents
The review loop for a coding agent often has a hidden delay: each change must be copied out and deployed somewhere before a person can check it. Session endpoints remove that delay for the build and review phase. You can watch the UI change live as the agent edits files. Product teams can try dashboards, prototypes, and internal tools without a dev server on their own machine.
This is not production hosting. The URL is session scoped, and every request needs credentials. But for the stage where you are iterating with an agent, it fits. The AWS sample shows the expected pattern: a chat pane, a live preview pane, and streaming agent steps.
Limits to note
The mechanism is deliberately narrow. allowedPorts accepts only ports between 8000 and 12000, with up to 5 entries or ranges. Your app must bind to 0.0.0.0 inside the session. The URL works only while the session lives. It is for building, testing, and reviewing, not for serving your users.
Also, a browser cannot sign requests on its own, so you need the local endpoint client from the bedrock-agentcore SDK. That adds a small piece of local setup. Once the local endpoint is running, the browser experience is normal.
What I would try
I would test this with a RAG chatbot UI or an internal dashboard that a client reviews. If the agent runs the dev server inside the session, the client can open the preview URL and ask for changes in the same loop. The value is not the preview URL by itself. It is watching the agent edit files and seeing the UI update before a deployment exists.
For regulated clients, I would keep the preview inside the authenticated Session endpoint and avoid exposing the app publicly. The permission model and session scope fit a review workflow better than a public staging link.