Amazon Bedrock AgentCore Session Endpoints: Watch Your Coding Agent's Web App Update Live
Primary source: AWS Machine Learning Blog, "Preview web apps live as your coding agent builds them with Amazon Bedrock AgentCore runtime" (Sundar Raghavan, Oct 30, 2026). Also: AgentCore docs, "Connect to runtime sessions through a session endpoint". Checked Oct 30, 2026 ~9 PM ET.
Oct 30, 2026: Coding agents can build a whole web app now. Checking that app is still slow: you copy it out, deploy it somewhere, look at it, then ask for a change and do it all again. In a new Oct 30 post, AWS shows how Session endpoints in Amazon Bedrock AgentCore runtime remove that step. You open the app inside the agent's sandbox from your own browser and watch the page change as the agent saves each file.
What a Session endpoint is
AgentCore runtime already runs each agent session in its own isolated microVM. A Session endpoint gives that one session an authenticated HTTPS URL. That URL forwards HTTP requests (method, path, query string and body) and WebSocket connections to ports you choose inside the session.
Per AWS, it carries:
- HTTP/1.1 and HTTP/2, including server-sent events and gRPC
- WebSocket connections, so dev servers with hot reload (the post uses Vite) push changes straight to your browser
It's not the same as a runtime endpoint (such as DEFAULT). A runtime endpoint reaches your agent; a Session endpoint reaches what your agent is running, such as a web preview or dev server.
How it works
Straight from AWS's post:
- You pick the ports. You set
allowedPortswhen you callCreateAgentRuntime: 1 to 5 entries, each a single port or a range within 8000–12000, excluding reserved platform ports. Your app has to listen on the port, bound to0.0.0.0. - The URL comes with the session. It's returned in the
X-Amzn-Bedrock-AgentCore-Runtime-Session-Endpoint-Urlresponse header ofInvokeAgentRuntime. - Every request is authenticated. IAM runtimes need a SigV4 signature on each HTTP request, HTTP/2 stream and WebSocket handshake, plus the
bedrock-agentcore:InvokeAgentRuntimeProxypermission. JWT-authorizer runtimes use a bearer token instead. "Knowing the URL doesn't grant access," AWS writes. - The hostname picks the port. You always connect on 443; a prefix like
8090--<session-endpoint-id>chooses the port inside the session. - It only lasts as long as the session. It's for building, testing and reviewing, not hosting. For real users, AWS points to a hosting service such as AWS Amplify Hosting.
Browsers can't sign their own requests, so the bedrock-agentcore SDK can open a local endpoint (the sample uses localhost:8088). It adds your credentials to each request before forwarding it.
The demo: "make it a dark coffee-house theme"
AWS's sample runs a coding agent (port 8080) that keeps a Vite site running on port 8090. A local page shows chat on the left and the live site on the right. Ask for a change and the site updates without a refresh when the agent saves the stylesheet.
The sample calls Claude Haiku 5.5 in Amazon Bedrock to decide what to edit. It needs Python 3.10+, bedrock-agentcore 1.25.2 or later, boto3 1.43.122 or later, and Node.js 22+. The code is in the awslabs/agentcore-samples repo.
What gets refused
The runtime answers refusals with an HTTP status, an empty body and an error code in a header:
| Request | Runtime response |
|---|---|
Port not in allowedPorts |
403 AccessDenied |
| No valid credentials | 403 AccessDenied or 401 AuthenticationRequired |
| Allowed port, nothing listening | 502 PortNotReachable |
| Session no longer exists | 404 SessionNotFound |
Requests are logged in AWS CloudTrail as InvokeAgentRuntimeProxy events. The local endpoint listens only on 127.0.0.1.
The fine print
- Session endpoints work with microVM runtimes, not the Instances compute type.
- URLs are reachable over public HTTPS. AWS PrivateLink isn't supported for inbound connections.
- The access controls don't separate the website from the agent. Both live in the same session, so AWS says to give the execution role only what the agent needs.
- If the session's compute is replaced, edits may be lost without persistent storage.
What's confirmed / not confirmed
Confirmed (AWS blog and AgentCore docs):
- Session endpoints give each AgentCore runtime session an authenticated URL to the ports you allow (1–5 entries in 8000–12000)
- HTTP/1.1, HTTP/2 (SSE, gRPC) and WebSocket support; SigV4 or JWT auth on every request
- microVM runtimes only; no inbound PrivateLink; CloudTrail logging as InvokeAgentRuntimeProxy
- The refusal codes in the table above
Not confirmed:
- Which AWS Regions have Session endpoints. The post only says "an AWS Region where AgentCore runtime Session endpoints are available."
- Pricing. The post gives no separate price for Session endpoints; it only says to clean up the sample "to avoid ongoing charges."
- The exact date the feature became available. The blog is dated Oct 30 and tagged "Announcements," but it doesn't say when the API first shipped.
- Folder names in the sample repo. The post names two different paths (14-remote-access and .../16-session-endpoints), so check the repo before linking a specific folder.
Related
Up: AI
