fix: add workflow_dispatch to sync-preview workflow#1255
Merged
Conversation
Allows manual triggering of the sync-preview workflow from the GitHub Actions UI while retaining the automatic push-on-main trigger.
github-actions
Bot
added
size/xs
Hweinstock
approved these changes
May 14, 2026
Contributor
Package TarballHow to installnpm install https://github.com/aws/agentcore-cli/releases/download/pr-1255-tarball/aws-agentcore-0.13.1.tgz |
|
Looks good to merge — small, low-risk change. Adding |
github-actions
Bot
removed
the
agentcore-harness-reviewing
Contributor
Coverage Report
|
jesseturner21
added a commit
that referenced
this pull request
May 14, 2026
* feat(typescript): scaffold TypeScript language support (WIP checkpoint) Unblocks TypeScript as a language option in the generate path and teaches the spec builder to emit NODE_22 / main.ts defaults when language=TypeScript. Templates, node setup helper, dev-server Python-only guard removal, tests, and docs still to come — see docs/TYPESCRIPT_SUPPORT_HANDOFF.md for the full remaining scope and plan link. - schema: add DEFAULT_NODE_VERSION, DEFAULT_ENTRYPOINT_BY_LANGUAGE, DEFAULT_RUNTIME_BY_LANGUAGE constants - tui: remove disabled=true from TypeScript LANGUAGE_OPTIONS entry - tui: filter SDK list to Strands-only when language=TypeScript - validate: drop the --language TypeScript reject; add Strands-only gate for TS - schema-mapper: branch entrypoint/runtime on config.language Confidence: medium Scope-risk: narrow Not-tested: end-to-end create/deploy — templates not yet authored * docs(typescript): add progress tracker for TS support initiative Living checklist alongside the handoff doc. Tracks phases 0-8, captures verification-sweep results, and reserves a commit log so the next person can reconstruct state from this file + git log. Confidence: high Scope-risk: narrow * docs(typescript): log 3417f9a in progress tracker Confidence: high Scope-risk: narrow * feat(typescript): unblock dev mode for TS agents (Phase 2) Drop the Python-only guard in isDevSupported. CodeZipDevServer already branches on entrypoint extension and selects `npx tsx watch` for non-Python agents, so the guard was the only thing rejecting TS entrypoints. Constraint: Dev-server spawn path must stay unchanged for Python agents Rejected: Add an explicit TypeScript allow-list branch | redundant — extension check already distinguishes, extra branch adds drift risk Confidence: high Scope-risk: narrow Not-tested: TS-specific unit test for spawn config (deferred to Phase 6) * docs(typescript): log a487f19 in progress tracker * feat(typescript): author TS/Strands HTTP template assets (Phase 3) Add src/assets/typescript/http/strands/ with gitignore, package.json, tsconfig.json, main.ts, README.md, mcp_client/client.ts, model/load.ts, and capabilities/memory/session.ts — mirroring the Python Strands templates surface-for-surface, keyed off the same Handlebars variables. Update asset snapshot baseline (8 new TS files + file-listing diff). Align three stale tests with the Phase 1/2 validator + dev-server changes: accept TS+Strands in validateAddAgentOptions; treat Node entrypoints as dev-supported in getDevSupportedAgents / getDevConfig. Extend .prettierignore to skip src/assets TS/JSON template files — these are Handlebars templates with {{...}} expressions that do not parse as TypeScript. ESLint already ignores src/assets via eslint.config. Constraint: SDK surface for @strands-agents/sdk + bedrock-agentcore TS is still RC; templates are written against the surface described in the handoff Rejected: Run prettier over the Handlebars TS templates | they do not parse as TS — same reason Python templates with {{...}} aren't formatted as Python Confidence: medium Scope-risk: narrow Directive: Verify SDK event-type names, model-class names, and memory import path against the actual tarballs before shipping — see Known gotchas in docs/TYPESCRIPT_SUPPORT_PROGRESS.md Not-tested: Rendered templates have not been compiled or run against real SDKs (Phase 6 integ + Phase 8 E2E) * docs(typescript): log 6f1aeed + f6ed2e9 in progress tracker * feat(typescript): add container template for TS agents (Phase 4) src/assets/container/typescript/Dockerfile uses node:22-slim with a cached deps layer (npm ci --omit=dev, fallback to npm install when no lockfile) and runs `npx tsx main.ts`. Exposes 8080/8000/9000 to match the Python Dockerfile contract. Non-root bedrock_agentcore user mirrors Python. Update asset file-listing snapshot for the two new files. Constraint: Dev and container runtimes should share one entrypoint shape so main.ts stays the single source of truth Rejected: Add a tsc build step + `node dist/main.js` CMD | adds a build surface and diverges dev vs container semantics; defer until image size or cold start becomes a problem Confidence: medium Scope-risk: narrow Not-tested: Container build + AgentCore deploy against a live runtime (Phase 6 E2E) * docs(typescript): log 003f672 + 076a4aa in progress tracker * feat(typescript): Node setup helper + create-flow wiring (Phase 5) Add src/cli/operations/node/setup.ts with setupNodeProject({projectDir}) that runs `npm install` and returns a structured result, mirroring the Python setup helper. Export via a new node/ operations barrel. Wire into useCreateFlow so a TypeScript create-path scaffold runs `npm install` in app/<name>/ after the agent is added. Add a matching entry to getCreateSteps so the progress UI reflects the step. Unit tests mirror python/setup.test.ts (8 specs). checkCreateDependencies requires no change — npm is already checked unconditionally (needed for CDK synth) and uv is already gated to Python. Node version is likewise checked unconditionally. Constraint: Fresh scaffolds don't ship a lockfile Rejected: Use `npm ci` | fails without package-lock.json; switching to `npm ci` after the first install is a later optimization Rejected: Mark npm_not_found as a hard error | keep parity with Python (uv failure is a warn, not error) so create still succeeds and the user can install deps manually Confidence: high Scope-risk: narrow Not-tested: End-to-end scaffold run against a real npm registry (Phase 8) * docs(typescript): log f015ce7 + 5c2af7d in progress tracker * test(typescript): add TS dev-server spec + create-flow integ block; fix spawn entrypoint rewrite Adds a TypeScript HTTP spec to codezip-dev-server.test.ts asserting the spawn is `npx tsx watch <entry>` with LOCAL_DEV env plumbed through. Adds a TypeScript block to the create integ suite that scaffolds a Strands/Bedrock TS agent and asserts the core generated files (main.ts, package.json, tsconfig.json, model/load.ts, mcp_client/client.ts). Fixes a latent bug in CodeZipDevServer where the non-Python spawn path was applying a Python-style module-path rewrite (`.replace(/\./g, '/') + '.ts'`), which turned `main.ts` into `main/ts.ts`. The entrypoint is now passed literally to tsx. Constraint: TS create integ must stay offline-safe — skips npm install via runCLI's skipInstall flag. Rejected: Shelling out to real `npm install` in the integ test | too slow + flaky on CI without a registry mirror. Confidence: high Scope-risk: narrow Directive: The non-Python dev-server spawn path passes the entrypoint literally — do not re-introduce Python module-path rewriting here. Not-tested: Real `npm install` end-to-end for TS scaffolds (covered manually in Phase 8). * docs(typescript): log c22147d in progress tracker * test(typescript): add TUI walkthrough for create TypeScript + Strands Mirrors the create-flow pattern from lifecycle-config.test.ts. Drives `agentcore create --language TypeScript --framework Strands` through the advanced-no path, confirms, and asserts the generated agentcore.json has runtimeVersion "NODE_22" and entrypoint "main.ts". Runs with AGENTCORE_SKIP_INSTALL=1 so the scaffold stays fast and offline-safe. Constraint: Walkthrough must not require a network-reachable npm registry. Rejected: Exercising advanced-settings branch too | already covered by lifecycle-config.test.ts for Python; TS path reuses the same wizard. Confidence: medium Scope-risk: narrow Not-tested: Real npm install end-to-end (covered manually in Phase 8). * docs(typescript): log 7af265e in progress tracker * fix(typescript): replace Python-only guard in create validator with Strands gate The create command's validator still hard-rejected --language TypeScript with "TypeScript is not yet supported", which shadowed all the Phase 1–5 plumbing for TS agents. The add-agent validator already performs the Strands-only gate, but the create path was missed. Replaces the hard reject with the same Strands-only gate used by the add command: TypeScript is accepted, but non-Strands frameworks produce a clear "Framework X is not yet available for TypeScript" error. The generic "Invalid language" message now also lists TypeScript alongside Python. Updates the corresponding unit test (previously asserted the old error message) to cover both the TS+Strands happy path and the TS+non-Strands rejection. Constraint: Create and add validators must agree on which TS frameworks are permitted. Rejected: Leave the add validator as the only gate | create path is reachable directly from the CLI and must reject non-Strands TS itself. Confidence: high Scope-risk: narrow Directive: Keep create/validate.ts and add/validate.ts TS gates in lockstep — both must restrict TypeScript to Strands until other TS templates land. * docs(typescript): phase 7 user docs + phase 8 verification log Adds TypeScript coverage to the user-facing docs: - frameworks.md: new "Supported languages" table + Strands-only note, TS example in the Strands section. - local-development.md: new "TypeScript Agents" subsection covering the npm + tsx watch dev loop and AGENTCORE_SKIP_INSTALL. - commands.md: --language row now lists TypeScript (Strands-only) with a cross-link, plus a TS create example. - container-builds.md: new "TypeScript Dockerfile" subsection matching the generated template (node:22-slim, non-root, tsx entrypoint, agentcore.json example). - README.md: Strands row annotated "Python + TypeScript". Also logs Phase 7 completion and Phase 8 partial results in the progress tracker — unit + integ suites green, manual agentcore dev/deploy runs and the gated E2E container deploy test are still outstanding. Confidence: high Scope-risk: narrow Not-tested: Manual agentcore create -> dev -> deploy walkthrough deferred until credentials are refreshed. * docs(typescript): add manual test plan with progress-tracker checklist Adds docs/TYPESCRIPT_SUPPORT_TEST_PLAN.md — a hands-on verification checklist for TypeScript Strands support that a tester can work through top-to-bottom. Structure: - Metadata block (tester, date, CLI version, Node/npm/platform) - 9 sections: prerequisites, automated suites, validator checks, scaffold, local dev, non-Strands rejection, CodeZip deploy + invoke, optional container build + deploy, docs smoke, Python regression - Each step has explicit commands, expected outcomes, and a [ ] / [x] / [!] / [~] status box - Known limitations and failure-capture guidance at the bottom Intended as a companion to docs/TYPESCRIPT_SUPPORT_PROGRESS.md — the progress tracker records what was built; this plan records what was actually tested end-to-end. Confidence: high Scope-risk: narrow Not-tested: The plan itself — it needs a first human pass to shake out any missing steps. * docs(typescript): add code pointers to TS test plan for targeted fixes Extends docs/TYPESCRIPT_SUPPORT_TEST_PLAN.md with two kinds of pointers: - A top-level "Code map" table listing every concern (validator, templates, dev-server, packaging, TUI, etc.) alongside the primary source file and its test file. One-stop reference for a fixer. - Inline "Fix pointers if Section N fails" blocks after sections 2, 3, 4, 5, 6, and 7. Each explicitly names the file to edit and the corresponding test file, so a tester who hits a red box can jump straight to the right place without re-deriving the architecture. Rationale: the progress tracker lists what was built commit-by-commit, but the tester who follows the plan needs to know where to look when a step fails. Surfacing the files inline saves them from grepping the repo mid-bug. Confidence: high Scope-risk: narrow Not-tested: Link rot — these paths are accurate as of the latest commit but may drift if future refactors move files. * fix(typescript): make scaffolded TS agent installable and bootable Two bugs blocked `agentcore dev` for scaffolded TypeScript agents: 1. `npm install` failed with ERESOLVE. bedrock-agentcore@0.2.2 declares `@strands-agents/sdk >=0.1.0` as a peerOptional, and npm excludes pre-releases (1.0.0-rc.4) from plain ranges. Added an `overrides` block pinning bedrock-agentcore's peer to the root SDK version. Also added the OpenTelemetry / AWS SDK / express / zod peers that Strands SDK expects at runtime as direct deps so they resolve deterministically. 2. `app.run()` threw because `new BedrockAgentCoreApp()` with no args is rejected by the 0.2.2 constructor. Rewrote the template to pass `{ invocationHandler: { process } }` to the constructor instead of assigning to `app.invocationHandler` post-construction. Verified end-to-end: fresh `agentcore create --language TypeScript` → `agentcore dev` binds :8080, Fastify serves `/invocations`, agent streams a 200 response in ~2.7s, and `tsx watch` hot-reloads on edits. Constraint: bedrock-agentcore@0.2.2 peerOptional excludes pre-release SDKs Rejected: bump Strands SDK past 1.0.0-rc.4 | no stable release available yet Confidence: high Scope-risk: narrow Not-tested: Container build path and MCP gateway variant of this template * fix(typescript): run npm install during non-interactive create for TS projects Non-interactive `agentcore create --language TypeScript` scaffolded files but never ran `npm install`, so the resulting project could not boot `agentcore dev` without a manual install step. Python had the equivalent `setupPythonProject` call; TypeScript had no matching branch. Added a `setupNodeProject` invocation that runs when language=TypeScript and `--skip-install` is not set. npm failures (ERESOLVE, missing npm, etc.) are surfaced as warnings on the result rather than aborting the whole create — the scaffold is still useful and the user can retry. Also added a TypeScript branch to `getDryRunInfo` so `--dry-run` lists the TS files that would be created (main.ts, package.json, tsconfig.json, model/load.ts, mcp_client/client.ts) instead of an empty `app/` entry. Constraint: Must match Python's behavior so non-interactive flow is symmetric Confidence: high Scope-risk: narrow * fix(typescript): surface real npm install error in interactive create TUI The interactive TS create flow previously collapsed every npm install failure into "Failed to set up Node environment. Run npm install manually to see the error." That hid ERESOLVE and other diagnostic output behind a manual re-run, which was especially painful during the rc.4/peer-dep work since the user had no signal why install failed. Now the warn message includes the first meaningful line of npm stderr (stripped of the `npm error`/`npm warn` prefix, capped at 160 chars), differentiates `npm_not_found` from install failures, and logs every non-empty line of npm output as a sub-step so the full trace is visible in the TUI without re-running. Confidence: high Scope-risk: narrow * docs(typescript): add completed test plan results for TS support bug bash Filled-in copy of docs/TYPESCRIPT_SUPPORT_TEST_PLAN.md with run data, outputs, and checkbox state for each scenario exercised during the TypeScript support bug bash. Captures what works today, what required the template and create-flow fixes landing in this batch, and the residual gaps (container build path, MCP gateway variant) that need follow-up. Confidence: high Scope-risk: narrow * fix(typescript): make container build succeed for scaffolded TS agent `agentcore dev` with build=Container failed during image build with `useradd: UID 1000 is not unique`. The node:22-slim base image already ships a `node` user at UID 1000, so creating `bedrock_agentcore` at the same UID collided. Delete the preexisting node user before creating bedrock_agentcore so UID 1000 is free. Verified with a fresh TS Container scaffold: image builds in ~12s, container boots, `/ping` returns Healthy, and `/invocations` routes to the agent. Constraint: Must keep bedrock_agentcore at UID 1000 to match Python image Rejected: Pick a different UID | diverges from Python container contract Confidence: high Scope-risk: narrow Directive: node:22-slim base reserves UID 1000 for `node` — leave the `userdel -r node` in place if this image is ever rebased onto a different tag, verify no other user at UID 1000 first * fix(typescript): move tsx into dependencies so containers boot without re-install The TS Container Dockerfile runs `npm ci --omit=dev`, which drops tsx because it was a devDependency. The container then fell back to `npx tsx main.ts` at runtime, which re-downloaded tsx from the registry on every boot (~4–6s added latency, plus a hard dep on network access at container start). Moved tsx to dependencies. Preinstalled in the image, no network call at boot, container ready ~5s instead of 10+. Local `tsx watch` dev behavior is unchanged since runtime-present deps are still resolvable by the `dev` script. Snapshot updated to reflect the new dep layout. Confidence: high Scope-risk: narrow * fix(typescript): reject --protocol MCP + --language TypeScript with a clear error `agentcore create --protocol MCP --language TypeScript` previously got past validation and crashed in the renderer with an ENOENT pointing at a non-existent template directory (`src/assets/typescript/mcp/standalone/base`). The MCP TS template has not been authored yet. Added an explicit guard in both `create` and `add agent` validators that returns "MCP protocol is not yet supported for TypeScript. Use --protocol HTTP or --language Python." before we try to render the missing template. Same message for both commands so users hitting it from either path see the same guidance. Follow-up: when the MCP TS template lands, delete these two guards. Confidence: high Scope-risk: narrow Directive: Remove these guards in lockstep with the MCP TS template — leaving one in place will continue rejecting a valid combo. * fix(typescript): enable TypeScript option in interactive create wizard The language picker in the interactive `agentcore create` wizard had TypeScript marked `disabled: true` with a "(coming soon)" label, so users could not pick it from the TUI even though non-interactive `agentcore create --language TypeScript` worked end-to-end. Removed the disabled flag and "(coming soon)" label now that the TS HTTP/Strands template runs through create, dev (CodeZip), and dev (Container) verified end-to-end. Also dropped the now-dead `'disabled' in o` branch in GenerateWizardUI since no LANGUAGE_OPTIONS entry carries the field anymore. Confidence: high Scope-risk: narrow * fix(typescript): gate MCP and A2A protocols behind Python-only until TS templates land `agentcore create` exposed MCP and A2A in the TUI protocol picker for any language. Both trigger a renderer ENOENT for TypeScript because the templates (`typescript/mcp/...`, `typescript/a2a/...`) do not exist yet. - TUI: protocol step now disables MCP and A2A when language=TypeScript, so the picker reflects what is actually supported. - Validators: replaced the MCP-only TypeScript guard (landed in 38e9973) with a general `protocol !== 'HTTP' && language === 'TypeScript'` check, so A2A is now rejected with the same friendly message instead of crashing in the renderer. Follow-up: when MCP and/or A2A TS templates land, drop the disabled flag in GenerateWizardUI and the validator guards in both create and add — all three must move in lockstep. Confidence: high Scope-risk: narrow Directive: The validator and TUI guards are paired with a missing template. Do not remove one without confirming the corresponding template directory exists under `src/assets/typescript/`. * feat(dev): enable dev mode for TypeScript agents (CodeZip + Container, browser + no-browser) Unblock TypeScript agents in `agentcore dev` across all four combinations: CodeZip/Container x browser/no-browser. The underlying dev server already handled TypeScript in the CodeZip spawn path (npx tsx watch) and the Container path is language-agnostic - only the user-facing guards and messages still claimed Python-only. Also wires a node-deps install step parallel to ensurePythonVenv so a freshly cloned TS project works on first invocation. - command.tsx: drop "requires Python agents" message - DevScreen.tsx: drop "requires Python agent" message - codezip-dev-server.ts: add ensureNodeDeps (detects pnpm/yarn/npm via lockfile) - codezip-dev-server.test.ts: cover install-on-missing and skip-on-present Constraint: Container path must remain language-agnostic - no Dockerfile assumptions Rejected: Split CodeZip into Python/Node subclasses | spawn branch is 8 lines, not worth the abstraction Confidence: high Scope-risk: narrow Not-tested: End-to-end matrix against live AWS; pre-existing dev.test.ts failures unrelated to this change * fix(dev): detect TS server readiness in terminal TUI mode The useDevServer hook only checked for Python/uvicorn startup strings ("Application startup complete", "Uvicorn running") to transition from "starting" to "running". TS agents log "Server listening" instead, causing the TUI to stay stuck on "Starting..." forever. Add "Server listening" to the readiness detection pattern. Confidence: high Scope-risk: narrow * fix(typescript): use correct Strands SDK stream event types in template The Strands TypeScript SDK (@strands-agents/sdk 1.0.0-rc.4) emits modelStreamUpdateEvent with nested modelContentBlockDeltaEvent, not contentBlockDelta. The template filter matched nothing, so the async generator yielded zero chunks and agentcore dev showed empty response. * fix(invoke): include text/event-stream in Accept header for HTTP invoke The SigV4 invoke paths sent Accept: application/json, causing 406 Not Acceptable from container agents whose bedrock-agentcore runtime only produces SSE streams. The bearer-token, MCP, A2A, and AGUI paths already included text/event-stream — this aligns the two remaining HTTP invoke functions. Constraint: bedrock-agentcore Node.js runtime returns 406 when Accept header lacks text/event-stream and handler is an async generator Rejected: Change only the streaming path | non-streaming path also needs it for containers that always stream Confidence: high Scope-risk: narrow * fix(typescript): disable memory for TypeScript agents and clean up templates TypeScript Strands SDK does not yet support the memory session manager, so the generate wizard now skips the memory step for TypeScript agents and the template removes the memory-related Handlebars blocks. Also filters protocol options to only show HTTP for TypeScript (instead of showing disabled options) for a cleaner UX. * feat(typescript): add Vercel AI SDK framework for TypeScript agents Add VercelAI as a new framework option alongside Strands, LangChain, GoogleADK, and OpenAIAgents. Supports all 4 model providers (Bedrock, Anthropic, OpenAI, Gemini) with HTTP protocol, both CodeZip and Container deploy modes. Includes template assets (main.ts, model/load.ts with per-provider Handlebars conditionals, package.json, tsconfig.json), VercelAIRenderer, renderer factory wiring, TUI wizard option, and validation gate updates. Confidence: high Scope-risk: narrow * fix(vercelai): fix dependency versions, model ID, and Bedrock credentials The Vercel AI template had outdated dependency versions (ai@^4.3.0) incompatible with bedrock-agentcore@0.2.2 which requires ai@>=6.0.0. The Bedrock model ID was invalid, and the provider lacked credential chain support needed for deployed AgentCore Runtime environments. Constraint: @ai-sdk/amazon-bedrock does not use AWS SDK default credential chain Rejected: Explicit env var credentials | not available in AgentCore Runtime container Confidence: high Scope-risk: narrow * fix(dev): prefer explicit credentials over AWS_PROFILE in container dev When both AWS_ACCESS_KEY_ID and AWS_PROFILE are set, the SDK credential chain inside the container prefers AWS_PROFILE. But the mounted ~/.aws files have 600 permissions owned by the host user, so the container's bedrock_agentcore user cannot read them — falling back to EC2 instance metadata which uses the wrong account. Now omits AWS_PROFILE from the container env when explicit credentials are available, so the credential chain finds env var creds first. Constraint: Container user uid differs from host user uid Rejected: chmod the mounted credentials | security risk, read-only mount Confidence: high Scope-risk: moderate * fix(dev): resolve AWS credentials on host for container dev mode Containers don't have credential_process tools like ada installed, so mounting ~/.aws and relying on the SDK to resolve credentials inside the container fails. Instead, resolve credentials on the host via `aws configure export-credentials` and pass them as env vars. Constraint: credential_process (e.g. ada) is not available inside containers Rejected: Install ada in container | bloats image, not portable Confidence: high Scope-risk: narrow * fix(dev): detect and skip container runtime shims that masquerade as real runtimes The container runtime detection previously only checked `which` + `--version` to validate a runtime. Toolbox shims (e.g., ~/.toolbox/bin/finch wrapping ada) pass both checks but don't support container operations like build/run. Add a `build --help` probe after the version check. Skip the runtime if: - The probe exits with non-zero code, OR - The probe exits 0 but stderr contains "unknown command" or "not found" (handles shims that always exit 0 regardless of errors) Constraint: Cannot use `docker info` as it requires daemon access and triggers password prompts Rejected: Only checking exit code | ada shim exits 0 for all commands Confidence: high Scope-risk: narrow Not-tested: Shims that swallow stderr entirely (would need stdout content validation) * fix: set typescript agent port to 8080 * chore: remove development tracking docs from PR Remove TYPESCRIPT_SUPPORT_PROGRESS.md, TYPESCRIPT_SUPPORT_TEST_PLAN.md, and TYPESCRIPT_SUPPORT_TEST_PLAN_RESULTS.md — these were internal development artifacts not intended for the repository. * fix: update runCLI call to use options object and format frameworks.md The runCLI signature changed from a boolean to an options object on main. Also fix prettier formatting in docs/frameworks.md. * fix(test): update container-dev-server test for resolveHostCredentials spawnSync call The resolveHostCredentials method added in the credential resolution commit calls spawnSync for aws configure export-credentials. Update the test to assert the specific rm call instead of counting total spawnSync invocations. * style: format container-dev-server test with prettier * fix: wire up agent templates with PORT option * feat: add Node.js OTEL support and fix CJS import.meta.url crash - Add otel-register.ts template for both Strands and VercelAI - Bundle otel-register.ts as second esbuild entrypoint alongside main.js - Fix CJS import.meta.url crash with banner/define shim - Re-enable OTEL for TypeScript in schema-mapper (CDK now handles it) - Add OTEL SDK deps to VercelAI template package.json * fix: switch Node CodeZip bundling to ESM format AgentCore runtime executes .js files as ES modules. CJS format caused "require is not defined in ES module scope" error. Switch to ESM format where import.meta.url works natively. * fix: add createRequire banner to ESM bundles for CJS compat Bundled CJS libraries (Fastify, OpenTelemetry) use dynamic require() for Node built-ins. ESM format breaks these calls. Fix by injecting createRequire(import.meta.url) banner so dynamic requires resolve. * fix: use CJS format with package.json type:commonjs in zip Match CDK constructs approach: output CJS and include package.json with type:commonjs so the AgentCore runtime treats .js files as CJS. * fix: copy dynamic require deps into _deps dir for Node CodeZip bundles bedrock-agentcore uses createRequire() to load @fastify/sse and @fastify/websocket at runtime. esbuild cannot statically resolve these, so they must be present on the filesystem. We copy them (and transitive deps) into a _deps/ directory and patch Module._resolveFilename in the banner to fall back to _deps/. * fix: update otel-register.ts to use OpenTelemetry SDK v2.x API Resource class was removed in @opentelemetry/resources v2.x. Use resourceFromAttributes() and pass spanProcessors in the NodeTracerProvider constructor instead of addSpanProcessor(). * test: fix node-packager tests and update snapshots for CJS bundling Mock fs module in node-packager tests since the packager now writes package.json and copies deps to the staging directory. Update asset snapshots for the new otel-register.ts template content. * fix: TypeScript template and packaging fixes for Node CodeZip - Change default entrypoint from main.ts to main.js (bundled output) - Relax process handler types to avoid esbuild type resolution issues - Add resolveNodeProjectPaths async helper for Node project packaging - Remove configBundles from CDK test fixture to match current schema * refactor: inline otel-register into main.ts for local + deployed tracing Import otel-register.js at the top of main.ts templates so OTEL instrumentation works both in agentcore dev (tsx runs main.ts directly) and deployed (esbuild inlines it into main.js). Removes the separate otel-register.js bundling step since it's now part of the main bundle. * test: update asset snapshots for otel-register import in main.ts * fix: use Resource class instead of resourceFromAttributes for OTEL v1.x compat The template package.json specifies @opentelemetry/resources ^1.30.1 which does not export resourceFromAttributes (a v2.x API). Use new Resource() which is the stable v1.x constructor. * fix(dev): use fixed port 8080 for TypeScript HTTP agents in web UI The published bedrock-agentcore SDK (<=0.2.3) hardcodes port 8080 in BedrockAgentCoreApp.run(), ignoring both the port option and PORT env var. The web UI was assigning a dynamic port and then failing waitForServerReady because the agent always bound to 8080. Constraint: SDK run() hardcodes port 8080, port param not yet published Rejected: Build SDK from source | adds build complexity for a workaround Confidence: high Scope-risk: narrow * fix(templates): fix TypeScript non-Bedrock model provider templates Three issues fixed: 1. Strands package.json missing model-provider-specific dependencies (@anthropic-ai/sdk, openai, @google/genai) — agents crashed on import. 2. Both Strands and VercelAI templates passed async getApiKey function reference where SDKs expected a resolved string. Refactored to await the key at initialization time with lazy-cached providers. 3. Strands OpenAI template missing required `api: 'chat'` parameter in OpenAIModel constructor. Also added fallback to standard env var names (ANTHROPIC_API_KEY, OPENAI_API_KEY, GEMINI_API_KEY) for local dev when the credential env var is not set. Constraint: withApiKey is async, SDKs expect sync string for apiKey Rejected: Pass function ref to SDK | SDKs don't support async apiKey Confidence: high Scope-risk: moderate Not-tested: deployed mode with withApiKey credential resolution * docs: update bugbash status — all Container + non-Bedrock combos tested All 6 Container + non-Bedrock provider combinations (Strands and VercelAI with Anthropic, OpenAI, Gemini) pass Create, Dev (logs), and Invoke. Web UI mode verified working for Container non-Bedrock providers. Confidence: high Scope-risk: narrow * docs: update bugbash status — deploy, invoke, and remove lifecycle tested - Strands+Container+Bedrock: deploy + invoke pass - Strands+Container+Anthropic: deploy passes, invoke fails (same credential resolution issue as CodeZip — Known Issue #1) - Remove + destroy lifecycle verified working Confidence: high Scope-risk: narrow * fix(templates): fix withApiKey call syntax in TypeScript non-Bedrock templates The templates were calling withApiKey(config, fn)() which passes the callback as a second argument to withApiKey (ignored), then calls the returned HOF with no arguments — resulting in fn=undefined. When the inner wrapper executes, it returns the apiKey string via fn(...) which crashes or returns undefined, causing "Could not resolve authentication method" errors on deployed invoke. Fixed to withApiKey(config)(fn)() which correctly chains the HOF: config → wrapper(fn) → wrappedFn() → apiKey string. Constraint: withApiKey is a curried HOF, not a two-arg function Rejected: Inline the identity client call | breaks SDK abstraction Confidence: high Scope-risk: narrow Not-tested: OpenAI and Gemini deployed invoke (same code path, same fix) * docs: update bugbash status — withApiKey fix resolves deployed invoke Confidence: high Scope-risk: narrow * fix(dev): allow web UI port fallback for TypeScript HTTP agents The web UI handler treated TS HTTP agents as needing a fixed port 8080. If 8080 was occupied, it errored instead of falling back. Now TS HTTP agents prefer 8080 but gracefully use the next available port, and the PORT env var is passed to the agent process. Also fixes flaky dev.test.ts tests that assumed port 8080 was free — they now target an unlikely-to-be-used port so connection-refused behavior is deterministic. Constraint: TS agent templates read process.env.PORT ?? '8080' Rejected: Keep fixed port for TS HTTP | breaks dev when 8080 is occupied Confidence: high Scope-risk: narrow * test(e2e): add TypeScript Strands and VercelAI e2e tests Add end-to-end tests for TypeScript agent templates with Bedrock: - ts-strands-bedrock: full lifecycle test for TypeScript + Strands - ts-vercelai-bedrock: full lifecycle test for TypeScript + VercelAI - e2e-helper: add language option to support TypeScript projects Constraint: Deploy will fail until AgentCore service accepts NODE_* for CodeZip Confidence: high Scope-risk: narrow * test(e2e): skip logs and traces tests for TypeScript agents Add skipObservability option to e2e helper to skip logs/traces tests that don't meaningfully validate trace content. * fix(templates): bump bedrock-agentcore SDK to ^0.2.4 The published SDK v0.2.2 hardcoded PORT=8080, ignoring the port option passed by app.run(). SDK v0.2.4 respects options.port, which is required for the port fallback fix to work end-to-end. Constraint: SDK must accept port option for CLI port fallback to function Confidence: high Scope-risk: narrow * fix(tui): remove duplicate project name in create-prompt phase The project name was shown twice — once in the screen header and once in the create-prompt body. Removed the body duplicate. * ci(e2e): add cdk_branch input to override CDK source branch Allows specifying which CDK repo branch to build from in E2E tests via workflow_dispatch. Defaults to main for PR runs. Useful when CLI changes depend on unreleased CDK features. * Revert "ci(e2e): add cdk_branch input to override CDK source branch" This reverts commit 816cef4. * Reapply "ci(e2e): add cdk_branch input to override CDK source branch" This reverts commit 19fdf00. * fix(templates): remove OTEL, session storage, and gateway from TS templates Simplifies TypeScript starter templates by removing OpenTelemetry instrumentation, session storage file tools, and gateway MCP client conditionals. Keeps a simple MCP client example for discoverability. Also addresses PR feedback: remove stale handoff/bugbash docs and fix "Strands-only" references to include Vercel AI. * fix(dev): use dynamic port assignment for TS HTTP agents in web UI Remove special-case that preferred port 8080 for TypeScript HTTP agents. Now uses the same uiPort+1+index scheme as Python agents, avoiding unnecessary 8080 collisions. * docs: add explanatory comments for container credentials and node path resolution * docs: add VercelAI to CLI help text and documentation VercelAI was fully supported in the codebase (schema, templates, assets, validation) but missing from user-facing help strings and docs. * fix: make reserved-name error message language-neutral The error said "Python package dependency" even for TypeScript projects. The reserved list is language-agnostic, so the message should be too. * fix: hide traces UI for TypeScript agents TypeScript agents don't support observability/traces. This change: - Adds `supportsTraces` boolean to InvokeConfig runtimes, computed from entrypoint - Guards trace URL display on invoke screen behind `supportsTraces` - Skips transaction search setup on deploy when no Python agents exist - Returns early with clear error from `agentcore traces list/get` for TS agents Constraint: Only Python agents have OpenTelemetry instrumentation Rejected: Check language field | entrypoint is more reliable and already available Confidence: high Scope-risk: narrow * fix(templates): rename handler to callback in Strands TS tool config The @strands-agents/sdk FunctionToolConfig requires `callback:`, not `handler:`. The incorrect field name caused the example addNumbers tool to silently never execute its function. Confidence: high Scope-risk: narrow * fix(templates): remove unused deps from Strands TS package.json Remove @aws-sdk/client-s3, express, and zod — none are imported by the template code. Reduces install size and avoids zod version conflicts with VercelAI templates. Confidence: high Scope-risk: narrow * docs(templates): fix stale README info in TS templates Remove incorrect "Fastify-based" description (SDK provides its own server) and replace hardcoded 0.0.0.0:8080 with accurate port info. Confidence: high Scope-risk: narrow * feat: instrument telemetry for dev command (#1223) * feat: instrument telemetry for dev command Add telemetry recording to the dev command across all execution paths: - Invoke: wrapped with withCommandRunTelemetry, emits on success/failure - Exec: wrapped with withCommandRunTelemetry for container exec - Server modes (--logs, --no-browser, browser): emit on SIGINT/exit Schema changes: - Expand Action enum to include 'exec' - Add UiMode enum ('browser' | 'terminal') - Add 'agui' to Protocol enum - Add ui_mode field to DevAttrs Refactored invoke helpers to throw instead of process.exit(1) so telemetry wrapper can record failures before exit. Attributes emitted: action, ui_mode, has_stream, protocol, invoke_count * refactor: use typed errors in dev command helpers + emit browser telemetry eagerly Error classification: - ConnectionError for connection-refused (new class in lib/errors/types.ts) - ValidationError for invalid user input (missing --tool, bad JSON, unknown command) - ResourceNotFoundError for missing container runtime Browser mode telemetry: - Emit telemetry eagerly via TelemetryClientAccessor before the blocking runBrowserMode call (which never returns). Do not copy this pattern — prefer withCommandRunTelemetry for commands that return. * feat: instrument telemetry for invoke command (#1227) * feat: instrument telemetry for invoke command * fix: use ValidationError, eliminate double config load, move header parsing inside telemetry wrapper - Use ValidationError for validation and prompt resolution failures - Pass pre-loaded InvokeContext into handleInvokeCLI to avoid reading config files twice on the happy path - Move parseHeaderFlags inside the telemetry wrapper so invalid -H values are recorded as failures * feat: upgrade agent inspector to 0.4.0 * feat: upgrade agent inspector to 0.4.1 * fix: replace third-party base image with AWS public ECR image (CVE-2026-31789) (#1250) * fix: replace third-party base image with AWS public ECR image Switch Python container Dockerfile from ghcr.io/astral-sh/uv:python3.12-bookworm-slim to public.ecr.aws/docker/library/python:3.12-slim to remediate CVE-2026-31789 (OpenSSL). The uv binary is copied from the official image via multi-stage COPY --from. Constraint: Must preserve uv-based dependency management workflow Rejected: pip install uv | adds network call and slower builds Confidence: high Scope-risk: narrow * fix: address review — use pip install uv, fix import command, update docs - Replace COPY --from with pip install uv==0.11.14 to fully eliminate third-party image pull at build time - Update agentcore import Dockerfile generation to use AWS ECR base image - Update docs/container-builds.md to reflect new base image setup Constraint: No AWS-hosted uv binary available; pip install is the cleanest path Confidence: high Scope-risk: narrow * fix: pin python base image to bookworm for reproducible builds Pin to python:3.12-slim-bookworm to prevent silent OS upgrade when Debian Trixie becomes the default slim tag. Confidence: high Scope-risk: narrow * fix: unpin uv version — install latest via pip uv is a single static binary with no OS dependencies, so pinning provides little security value while requiring periodic bumps. Confidence: high Scope-risk: narrow * fix: add workflow_dispatch trigger to sync-preview workflow (#1255) Allows manual triggering of the sync-preview workflow from the GitHub Actions UI while retaining the automatic push-on-main trigger. * fix: resolve merge conflicts between main and preview Combine preview's harness/alt-screen features with main's telemetry instrumentation (withCommandRunTelemetry wrapper). * fix: resolve type errors from merge conflict resolution - Export ConnectionError, ResourceNotFoundError, ValidationError from lib/errors barrel - Remove duplicate imports in dev/command.tsx - Fix ConnectionError constructor calls (expects string, not Error) - Fix InvokeResult/Result type mismatch in invoke telemetry wrapper - Add missing harnesses field to test fixture - Remove unused serializeResult import - Fix unnecessary type assertion * fix: regenerate package-lock.json to fix npm ci sync * fix: ensure JSON output for all invoke CLI error paths handleInvokeCLI now prints JSON for validation failures. The telemetry wrapper callback also catches throws from handleInvokeCLI and prints JSON before returning a failure Result. * fix: redact sensitive data in invoke CLI output (CodeQL) Add redactSensitiveText helper to strip bearer tokens, client secrets, and token values from invoke results before logging to stdout/stderr. --------- Co-authored-by: Jesse Turner <ajesstur@amazon.com> Co-authored-by: Avi Alpert <aalpert@amazon.com> Co-authored-by: Hweinstock <42325418+Hweinstock@users.noreply.github.com> Co-authored-by: Aidan Daly <99039782+aidandaly24@users.noreply.github.com> Co-authored-by: Avi Alpert <131792194+avi-alpert@users.noreply.github.com> Co-authored-by: Jesse Turner <57651174+jesseturner21@users.noreply.github.com> Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
workflow_dispatchtrigger to the sync-preview workflow so it can be manually run from the GitHub Actions UITest plan