AWS gives coding agents a live site preview straight from an isolated session

Amazon Web Services has added a Session endpoints feature to the AgentCore runtime. AgentCore runtime runs each AI agent session in its own isolated micro virtual machine. Until now, anything the agent started inside it, a website for example, was invisible from the outside. Now the session has a secured URL: open it in a browser and watch the coding agent build a web app. Every edit shows up on the page within seconds, before anyone has deployed anything to hosting.

Why watch the site while the agent writes code

Coding agents already build working dashboards, product pages and prototypes. The easiest way to check such work is by hand: open the app, click around, ask for a change, look at the result. The loop is fast as long as the app runs in the same place where the agent edits files. If you first have to copy it somewhere else and deploy it, every edit waits on a deploy, and review slows down to deploy speed.

Session endpoints remove that step. They are not a replacement for production hosting: AWS explicitly recommends serving the app to users through a service such as AWS Amplify Hosting. The endpoint is for building, testing and accepting what the agent has made.

How the demo setup works

The sample in the agentcore-samples repository has four parts:

• The coding agent runs in the session on port 8080 and edits the site's files with four tools: list, read, write and edit.
• The Vite dev server listens on port 8090, serves the site, and tells the browser over WebSocket about every saved file.
• On your machine, the PreviewApp application shows the page: chat on the left, the live site on the right. It sends your requests to InvokeAgentRuntime and opens a local entry point for the site.
• To make decisions, the agent calls the Claude Haiku 5.5 model in Amazon Bedrock.

The first InvokeAgentRuntime call starts the session, and the Session endpoint address comes back in the response header. After that, it's simple. You ask to switch the site to a dark coffee theme. The agent reads src/main.js, src/style.css and index.html, saves the styles, and the site changes without a page refresh. The agent's steps stream into the chat as server-sent events. The next request, making the "Order ahead" button green, goes the same way: the agent changes only style.css.

Six details to know when setting up

• You choose the ports. The allowedPorts parameter, set when you create the runtime, takes from 1 to 5 ports or ranges within 8000–12000, excluding reserved platform ports. An allowed port does not start a server by itself: the app must listen on it at 0.0.0.0.
• The URL arrives with the session, in the X-Amzn-Bedrock-AgentCore-Runtime-Session-Endpoint-Url header.
• Every request is authenticated. A runtime with IAM needs a SigV4 signature and the bedrock-agentcore:InvokeAgentRuntimeProxy permission; a runtime with a JWT authorizer needs a bearer token. Knowing the address is not enough.
• The port is selected by a prefix in the host name, for example 8090--<id>.runtime.bedrock-agentcore.<region>.on.aws. The client always connects to 443.
• HTTP/1.1, HTTP/2, server-sent events, gRPC and WebSocket all pass through.
• The endpoint is bound to a single session and dies with it.

A browser can't sign page requests with SigV4 on its own. So the bedrock-agentcore SDK opens a local endpoint on your machine at localhost:8088, which adds credentials to every request and WebSocket handshake. It listens only on 127.0.0.1 and rejects WebSocket connections from pages on other origins.

Separately, port 8081 sits in the session: the agent serves a /status route on it with a list of requests and changed files. Only the port number changes; the endpoint is the same. Port 8080 is deliberately not on the list: InvokeAgentRuntime reaches the agent even without a Session endpoint.

What the endpoint rejects and what to keep in mind

Runtime rejections arrive with an HTTP status, an empty body and an error code in a header, so they are easy to tell apart from errors in your own app:

• port outside allowedPorts: 403 AccessDenied;
• request without valid credentials: 403 AccessDenied or 401 AuthenticationRequired;
• allowed port with nothing listening: 502 PortNotReachable;
• URL of an already closed session: 404 SessionNotFound.

All requests land in AWS CloudTrail as InvokeAgentRuntimeProxy events. The runtime strips your authentication headers before forwarding, so the site never sees the signature.

There are limitations, too. It works only with microVM runtimes, not with the Instances compute type. The URL is reachable over public HTTPS, and AWS PrivateLink is not supported for inbound connections. If the runtime replaces the session's compute node, connections close, and the agent's edits may be lost without persistent storage. The site and the agent live in the same session and are not separated by permissions, so the execution role should get only the permissions it needs. The agent's file tools do not reach outside the site folder. If outsiders can send prompts, AWS recommends Amazon Bedrock Guardrails and a manual review of changes before publishing.

The sample deploys without Docker: the agent goes to Amazon S3 as a zip file via direct code deployment for Node.js 22. You need Python 3.10+, bedrock-agentcore 1.25.2+ and boto3 1.43.122+. After experimenting, run cleanup.py, which deletes the runtime, the code and the IAM role.

For teams building developer agents, this is a practical way to shorten the "ask, look, fix" loop. Just don't leave the preview on longer than necessary: the local endpoint runs with your credentials.