AWS adds live web app previews to Bedrock AgentCore sessions
AWS introduced live previews for web applications running inside isolated Bedrock AgentCore Runtime sessions, allowing developers to interact with an app as a coding agent edits it.
AWS has added live web application previews to Amazon Bedrock AgentCore Runtime, allowing developers to open and use an app inside the same isolated session where a coding agent edits its files. AWS says the Session endpoints workflow can shorten the review loop: the browser view stays available as the agent saves changes, removing the need for a separate deployment after every update.
A Session endpoint is an authenticated HTTPS URL tied to one Runtime session. It reaches application servers only on ports the developer explicitly allows and lasts only as long as the session. AWS positions the feature for development, testing and review, and recommends deploying the finished app to a separate hosting service for end users.
Developers set allowedPorts when creating a runtime. AWS documentation permits one to five non-overlapping entries, each covering a single port or an inclusive range from 8000 through 12000, with reserved platform ports such as 8443 excluded. Allowing a port does not start a server; the application must listen on that port and bind to 0.0.0.0.
With Session endpoints enabled, an InvokeAgentRuntime response can include the endpoint URL in the X-Amzn-Bedrock-AgentCore-Runtime-Session-Endpoint-Url header. Clients connect over TLS on port 443. A destination port followed by two hyphens at the start of the endpoint hostname routes the request to that port inside the session. The proxy preserves the HTTP method, path, query string and request body.
The URL is not a credential. Every HTTP request, HTTP/2 stream and WebSocket handshake must be authenticated. IAM callers sign requests with AWS Signature Version 4 and need the bedrock-agentcore:InvokeAgentRuntimeProxy permission for the runtime and runtime endpoint.
Browser requests cannot add SigV4 authentication on their own. AWS’s bedrock-agentcore SDK can instead expose a local endpoint that signs HTTP requests and WebSocket handshakes before forwarding them to the Session endpoint. The service supports HTTP/1.1 and HTTP/2 traffic, including server-sent events and gRPC, along with WebSocket connections over wss.
In AWS’s sample, a coding agent runs on port 8080 and a Vite development server runs on allowed port 8090. A local preview sends prompts to the agent through InvokeAgentRuntime and loads the website through the Session endpoint. Vite keeps a hot-reload WebSocket open through both the local and Session endpoints. When the agent saves a file, Vite pushes the change to the browser without a manual refresh.
A Session endpoint is distinct from a Runtime endpoint such as DEFAULT. The Runtime endpoint selects the agent version that receives InvokeAgentRuntime calls; the Session endpoint reaches applications running inside the resulting session. AgentCore’s runtime documentation says each session runs in a dedicated microVM with isolated CPU, memory and filesystem resources.
More news

Databricks launches Unity Gateway CLI to govern coding agents

Anthropic adds cross-session messaging to Claude Code so coding agents can coordinate

Cursor launches iOS app in public beta to direct cloud AI coding agents from a phone
Dmytro Spodarets·Jun 30, 2026