The Pulse
AWS Shows Developers How to Preview Apps in AgentCore Sessions
AWS’s walkthrough shows how developers can connect a live Vite app in an AgentCore session to a local preview page while a coding agent edits its files. The sample uses authenticated session endpoints, rather than adding a packaged live-pre
AI.info Team · Written with AI · fact-checked ·
AWS’s coding-agent preview is a sample developers assemble using Amazon Bedrock AgentCore session endpoints: one port serves the web app, and another exposes a status route. The example lets a developer watch the site change as the agent edits its files, without waiting for a separate deployment. But the preview is an authenticated development connection, not a public web address for shipping the finished app.
Two ports connect the preview to the session
In a post published October 30, AWS walks through a coding agent running in an isolated AgentCore microVM session. The sample serves a Vite website on port 8090 and a status route on port 8081; the agent itself receives requests on port 8080 through AgentCore’s separate invocation interface. Developers configure which ports a Session endpoint can reach, and the example allows only 8090 and 8081.
AWS’s sample brings the pieces together in a local preview page, with a chat pane beside the website. A local endpoint on the developer’s machine forwards browser traffic through the authenticated Session endpoint to the app in the runtime. The coding agent reads and edits the site’s files, while Vite watches for changes and sends them to the open page over a WebSocket.
Edits appear without a redeployment
The walkthrough demonstrates a request to switch the sample site to a dark coffee-house theme, followed by another to turn its “Order ahead” button green. The agent streams its steps into the chat pane as it works; when it saves the stylesheet, Vite pushes the update to the site pane without a refresh. The sample agent uses four file tools—list, read, write and edit—and calls Claude Haiku 5.5 in Amazon Bedrock to decide what to change.
The sample demonstrates how developers can inspect a working interface while the agent changes it, rather than exporting the files and deploying them after each edit. It is a demonstration, not a packaged coding-agent product. AWS points readers to a notebook and sample code in its AgentCore repository to deploy and run the setup.
The preview URL is temporary and permission-checked
Session endpoint requests require authentication. For runtimes using AWS Identity and Access Management, requests and WebSocket handshakes carry a Signature Version 4 signature; runtimes using a JSON Web Token authorizer use a bearer token. AWS says knowing the endpoint URL alone does not provide access, and requests are recorded in CloudTrail as InvokeAgentRuntimeProxy events.
The endpoint only reaches ports configured as allowed, and its URL lasts only as long as the session. A request to a disallowed port can receive a 403 response, while an allowed port with no server listening can return 502. The browser cannot add AWS signatures to its own requests, so the sample’s local client supplies credentials and listens only on the machine’s loopback address.
AWS draws a line between preview and publication
Knowing the URL doesn’t grant access.
Sundar Raghavan, AWS Senior Solutions Architect, writes that the access controls protect the route into the session, but do not isolate the website from the agent: both run in the same session. AWS advises limiting the execution role to the permissions the agent needs, and suggests filtering prompts and responses with Bedrock Guardrails when other people can prompt the agent.
Session compute replacement closes open connections, and edits may not persist unless the session uses persistent storage. AWS also warns developers to review the agent’s changes before publication. For an app meant to serve users, the post points to a separate hosting service, such as AWS Amplify Hosting; the Session endpoint is for building, testing and reviewing the app inside its runtime session.