Merge main into feature/revert-postmessage-origin-check#2744
Open
aws-toolkit-automation wants to merge 34 commits into
Open
Conversation
…wser (#2740) * fix: allow empty/null origin in postMessage check for Eclipse SWT Browser (#2736) * fix: allow empty/null origin in postMessage check for Eclipse SWT Browser Eclipse's SWT Browser widget loads the chat UI via file:// protocol, causing postMessage events to arrive with an empty string or "null" origin. The strict same-origin check added in 0dabdea rejected these messages, silently breaking chat in Eclipse — the backend returns a valid response but it never reaches the UI. Allow empty-string and "null" origins (which are what file:// and sandboxed opaque-origin contexts report) while still blocking real cross-origin attacks from HTTP(S) pages. Fixes aws/amazon-q-eclipse#555 Ref: P437110601 * fix: flip origin check to block-known-bad (only reject HTTP(S) cross-origin) Instead of allowlisting specific origins, only reject messages from real HTTP(S) cross-origin pages. This handles Eclipse (and any future non-HTTP host) without needing to know their exact origin value. The check now passes through messages with empty, "null", file://, or any non-HTTP origin — only blocking actual cross-origin HTTP(S) attacks. * test(chat-client): avoid leaking mynah-ui state from origin-check tests (#2741) The new origin-check tests dispatched real SEND_TO_PROMPT messages, which exercised mynah-ui DOM code (addToUserPrompt) on the shared global JSDOM. On slow CI runners this accumulated state pushed an unrelated mynah-ui test ('should create a new tab if current tab is loading') over its 10s timeout. Switch to an unknown command and assert via the rejection warn() spy so the origin-check logic still runs without touching mynah-ui. --------- Co-authored-by: Boyu <bywang@amazon.com>
…2746) The 'should create a new tab if current tab is loading' test in mynahUi.test.ts intermittently exceeds its 10s timeout on CI runners. The sibling test already takes ~8.5s, so 10s leaves no margin. Increase timeout to 30s to prevent flaky failures.
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: aws-toolkit-automation <>
…2742) Replace string-only path.resolve with fs.promises.realpath in requiresPathAcceptance, with an ENOENT fallback to realpath the parent directory plus basename for paths that don't exist yet (e.g., when the agent is creating a new file). This ensures workspace-boundary checks operate on the canonical resolved path rather than the literal input, so paths whose targets resolve outside the workspace are evaluated correctly. Adds a regression test exercising symlink resolution against the real filesystem.
Co-authored-by: aws-toolkit-automation <>
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: XiaoChen-amz <xxchen@amazon.com>
* feat: adding worklogs and chat pagination support * feat: adding unit tests for worklogs dedup cache and loadOlderWorklogs * feat: add routing test for loadOlderWorklogs command * fix: adding pagination to worklogs and chat * fix: review findings --------- Co-authored-by: pranavfi <pranavfi@amazon.com>
Co-authored-by: aws-toolkit-automation <>
* fix: surface lbv and checkpoint hitls regardless of job status mirrors the executing-branch behavior in the non-executing branch so the ide picks up pending hitls when the job reports planning or other non-executing statuses. pre-job mode-selection checkpoint stays filtered. * test: add coverage for non-EXECUTING HITL surfacing branches * refactor: extract isPreLbvCheckpoint guard for catch-all surfacer
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: aws-toolkit-automation <>
) * feat(integ): rewrite ATX integ tests for new chatty-agent handler Replaces the legacy DOTNET_IDE integ test flow with the new orchestrator agent (chatty-agent) flow, matching the VS Toolkit IDE behavior. Test changes: - Use TCP socket transport with Buffer-based JSON-RPC parsing to correctly handle Content-Length (bytes) vs string length (characters) for UTF-8 - Add sendMessage trigger after startTransform with 30s delay - Handle local-build-verification HITL with fake build result - Send "Mark this job as complete" chat message to reach COMPLETED - Poll without SolutionRootPath to avoid fetchWorklogs log flooding Handler improvements: - Add 30s request timeout to FES client via NodeHttpHandler - Add 30s timeout to all got.get() S3 download calls in handler and utils Tests validate: ListWorkspaces, CreateWorkspace, CreateJob, CreateArtifactUploadUrl, CompleteArtifactUpload, StartJob, SendMessage, GetJob, ListJobPlanSteps, ListHitlTasks, SubmitCriticalHitlTask, StopJob * style: format integ test files with prettier * fix: address PR review comments - Clean up orphan process/server on connection timeout (lspClient.ts) - Use import instead of require for NodeHttpHandler - Use consistent expect().to.be.oneOf() pattern --------- Co-authored-by: invictus <149003065+ashishrp-aws@users.noreply.github.com>
* feat: rejecting v1 agent jobs * feat: rejecting v1 agent jobs * feat: rejecting v1 agent jobs * feat: rejecting v1 agent jobs * feat: rejecting v1 agent jobs * feat: rejecting v1 agent jobs --------- Co-authored-by: pranavfi <pranavfi@amazon.com>
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
* chore: bump agentic version: 1.70.0 * feat: renaming toolkit title (#2762) Co-authored-by: pranavfi <pranavfi@amazon.com> --------- Co-authored-by: aws-toolkit-automation <> Co-authored-by: Pranav Firake <pranav.firake7@gmail.com> Co-authored-by: pranavfi <pranavfi@amazon.com>
* docs(chat-client): document per-host postMessage origin behavior Expand the handleInboundMessage JSDoc to describe how event.origin differs across IDE host environments -- notably Eclipse on Windows (Edge WebView2), which delivers an opaque empty/null origin for browser.setText()-injected HTML. Add a CONTRIBUTING section requiring chat-client message-handling and origin-validation changes to be reviewed against every supported host environment, not just same-origin hosts. * docs(chat-client): add host environment summary to README Add a concise table of how each IDE host embeds the chat webview (rendering engine, asset scheme, resulting origin, and message-delivery bridge) and note that inbound message-handling and origin-validation changes must be validated against every host environment.
…etTransform) (#2765) * fix(amazonq): preserve customer edits on checkpoint apply (DealerFx netTransform) applyChanges() in the netTransform language server laid every backend checkpoint diff onto the customer's solution with an unconditional fs.copyFileSync, with no check for files the customer had edited locally since the last apply. A later sync therefore silently overwrote manual fixes to an already-transformed project — the DealerFx data-loss report (8h of NuGet fixes clobbered by a retry). The watermark needed to detect this already existed (getModifiedFilesSince- Checkpoint, mtime > manifest.lastAppliedTimestamp) but was only consulted on the UPLINK (updateWorkspace); the DOWNLINK (applyChanges) never looked at it. Fix: - applyChanges takes the jobId (optional, defaults to '' for back-compat) and computes the customer-modified set once up front. A single guard (shouldPreserveUserFile) runs before each write in all three loops (filesAdded / filesUpdated / filesMoved): if the destination exists, was edited by the customer since the last apply, and differs from the incoming bytes, the customer's file is preserved (write — and, for a move, the unlink — is skipped), backed up under {jobId}/checkpoints/conflict-backups/, and recorded in the new conflictedFiles return field. The transform's version remains in the checkpoint after/ dir, so neither side is lost. - A byte-equal short-circuit (filesEqual) treats the agent's own identical re-emits as no-ops, so the per-job watermark never flags them as conflicts. - The interactive downlink (downloadCompletedStepArtifacts) now calls saveLastAppliedTimestamp like the diff-artifact path already did; without it the watermark was absent there and the guard would be a no-op on the exact path DealerFx lost edits on. Out of scope (deliberate): filesRemoved is left unguarded — deleting a customer-edited file the transform intends to remove is a product/semantic question, not a clobber. A true 3-way merge is infeasible client-side (no before/ baseline ships in the checkpoint); first-apply on a virgin manifest is unprotected by necessity. Tests: 6 new cases in the existing applyChanges suite. 22/22 applyChanges tests pass; compile clean. * fix(amazonq): prevent duplicate applyChanges bypassing user-edit protection downloadCompletedStepArtifacts loaded appliedSteps once before the loop. When the diff-artifact path (downloadDiffArtifact) already applied the same step earlier in the same getTransformInfo call, the stale snapshot missed it — causing a redundant second applyChanges that ran after the watermark was re-stamped, seeing 0 modified files and silently overwriting the customer's edits. Move loadAppliedCheckpoints inside the loop so each iteration reads fresh state from disk. * feat(amazonq): guard filesRemoved and filesMoved source against customer edits Extend the user-edit preservation to two previously unguarded paths: - filesRemoved: if the customer edited a file since the last apply and the transform wants to delete it, preserve the file on disk, back it up to conflict-backups/, and record the conflict. - filesMoved (source): if the customer edited the move source, skip the entire move (no copy to target, no unlink of source), back up the source to conflict-backups/, and record the conflict. The existing move-target guard remains unchanged. Tests: 3 new cases (move source preserved, remove preserved, remove proceeds when untouched). 38/38 applyChanges tests pass. * style: format atxTransformHandler.ts with prettier --------- Co-authored-by: Jiayu Wang <wwangjy@amazon.com>
* feat(amazonq): make updateWorkspace self-resolve the correct review HITL server-side When the client sends a stale or wrong stepId, the LSP now falls back to resolving the real pending review step from the plan tree, and if that misses (race where step already flipped to IN_PROGRESS), scans all active HITLs for one with a -review tag. This makes the client stepId advisory rather than load-bearing. * fix(amazonq): reset watermark after uplink so retry checkpoint applies cleanly After a successful updateWorkspace (customer edits uploaded to the agent), reset the lastAppliedTimestamp watermark. This ensures the incoming retry checkpoint isn't treated as a conflict — the customer explicitly asked to retry, so they expect the agent's output on disk. Also adds a second fallback to the C2-a step resolution: when the plan-based resolution misses (step already flipped to IN_PROGRESS on retry), scan all active HITLs for one with a -review tag. This covers the race where the review HITL is still alive but the step status has already transitioned. * fix(amazonq): detect edits in not-yet-transformed projects for uplink In a multi-project solution (A, B, C), if the customer edits Project B while Project A is transforming, those edits have mtime < lastApplied- Timestamp (set when A's checkpoint applied). The uplink missed them. Fix: updateWorkspace now uses the job-start time (createdAt) as the baseline for modified-file detection instead of lastAppliedTimestamp. This catches all edits made since the transform began, regardless of which project's checkpoint set the watermark. The conflict detection in applyChanges still uses lastAppliedTimestamp (correct for that purpose).
hasApproval() previously matched a stored approval when EITHER the config fingerprint OR the workspace hash matched (logical OR). This allowed an approval granted in one workspace to be silently reused in a different workspace that shipped an identical MCP server config, and allowed a previously-trusted workspace to mutate its config without re-prompting. Because MCP servers are spawned with cwd set to the requesting workspace, reusing consent across workspaces executes attacker-controlled files with the developer's privileges and no consent prompt (zero-prompt RCE). Require all three of (serverName, fingerprint, workspaceHash) to match so consent is bound to a specific workspace AND a specific config. The store already records workspaceHash per approval, so no data migration is needed: - cross-workspace reuse: blocked (workspaceHash differs) - config mutation in same workspace: blocked (fingerprint differs) Also scope removeApproval() to (serverName, workspaceHash) using its previously-unused configPath argument, so removing a server in one workspace no longer revokes consent for an identically-named server elsewhere. Rewrites the two unit tests that previously asserted the insecure reuse behavior and adds regression tests for per-workspace consent isolation and per-workspace revocation. Hardens against CVE-2026-12957.
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: Laxman Reddy <141967714+laileni-aws@users.noreply.github.com>
Co-authored-by: aws-toolkit-automation <>
…isServer (#2772) The QCodeAnalysisServer creates its own CodeWhispererServiceToken for the code review tool, but it was passing `undefined` for userContext and omitting the customUserAgent parameter entirely. This meant the SDK client created for code review (CreateUploadUrl, StartCodeAnalysis, etc.) had no IDE identifier in its user-agent header. The server-side Kiro Enterprise subscription handler validates the user-agent against an allowlist of known IDE clients. Without the IDE identifier, the check fails with AccessDeniedException. Fix: Pass getUserAgent() and makeUserContextObject() to the CodeWhispererServiceToken constructor, matching the pattern used by AmazonQTokenServiceManager.serviceFactory(). This affects all IDE plugins (VSCode, JetBrains, Eclipse, Visual Studio) using the agentic code review tool with Kiro Enterprise subscriptions. Fixes: P436405137
Bumping up language server runtime package versions: - @aws/chat-client-ui-types: 0.1.68 → 0.1.71 - @aws/language-server-runtimes: 0.3.18 → 0.3.19 - @aws/language-server-runtimes-types: 0.1.64 → 0.1.65 Updated in chat-client and server/aws-lsp-codewhisperer. Regenerated the corresponding package-lock.json entries.
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: aws-toolkit-automation <>
* feat(amazonq): block chat in AWS GovCloud regions (#2776) Short-circuit onChatPrompt and onInlineChatPrompt with an unsupported-region response when running in us-gov-east-1 or us-gov-west-1. Region is read from initializationOptions.aws.region, then AWS_REGION, then AWS_DEFAULT_REGION. Mirrors the startup gate in amazon-q-developer-cli. * fix(amazonq): extend GovCloud block to AgenticChatController (#2777) * fix(amazonq): extend GovCloud block to AgenticChatController Follow-up to #2776. The shipped runtime (agent-standalone via qAgenticChatServer manifest) uses AgenticChatController, not the legacy ChatController that #2776 patched. Apply the same getGovCloudUnsupportedResponse guard at the top of AgenticChatController.onChatPrompt and .onInlineChatPrompt. * revert(amazonq): remove GovCloud block from legacy ChatController Scope the GovCloud region block to AgenticChatController only, which is what the shipped agent-standalone runtime (used by amazon-q-vscode and JetBrains via the qAgenticChatServer manifest) actually runs. Other downstream consumers of the legacy ChatController (DEXP, iam-webworker, etc.) can opt into the same guard on their own timelines. Leaves getGovCloudUnsupportedResponse and GOV_REGIONS in chat/utils.ts, since AgenticChatController still consumes them.
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
…ironments (#2778) * test(chat-client): cover postMessage origin handling for all host environments Extend the Eclipse origin regression tests from #2740 to every supported IDE host environment, so a future change to the handleInboundMessage origin check cannot silently break a single host. Adds a table-driven suite (HOST_ORIGIN_CASES) that mirrors the host-environment matrix in chat-client/README.md and asserts the accept/reject outcome for each host's origin format: - accepts: VS Code (vscode-webview://), JetBrains and Visual Studio and SageMaker (same-origin), Eclipse on macOS/Linux (WebKit same-origin), Eclipse on Windows (Edge WebView2 empty "" / "null" origin), and file:// - rejects: cross-origin HTTPS, cross-origin plain-http, and same-host different-subdomain pages (the origin !== window.location.origin branch) Because the origin check compares event.origin against window.location.origin, each case runs in its own JSDOM served from the host's real page origin; the shared about:blank harness reports origin "null", under which the same-origin HTTP hosts would never exercise that comparison. Test-only change; no runtime behavior is modified. Guards against regressions of the Eclipse-on-Windows outage (aws/amazon-q-eclipse#555, fixed in #2740). * test(chat-client): strengthen origin coverage — opaque host reject + delivery assert Address two gaps in the host-environment origin suite: 1. Add a reject case where the host page origin is opaque ("null") — i.e. Eclipse on Windows, the host the origin fix was written for. The other reject cases use an http(s) page, so a refactor that only enforced the check on http(s) pages would silently disable it on the opaque-origin host and leave every reject case green; this case fails on that regression. Drop the redundant plain-http reject case (it takes the same startsWith('http') branch as the https one). 2. Assert the accepted path positively: the message clears the origin gate and reaches the command router (unknown-command telemetry fires exactly once), rather than only asserting the absence of an untrustedOrigin rejection. A regression that silently swallowed inbound messages would now fail. Test-only; no runtime behavior changes. * test(chat-client): close per-case JSDOM to avoid mynah-ui state leak The host-environment origin suite creates a fresh JSDOM (and a createChat / mynah-ui instance) per case but never tore them down, so timers/observers accumulated on the shared global window across cases. This is the same state-leak class that made an unrelated mynah-ui test flaky under CI load (see #2741 / #2746) and can push it past its timeout. Track each case's JSDOM and call window.close() in afterEach so state does not carry over. Test-only.
Co-authored-by: aws-toolkit-automation <>
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
11 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.
Automatic merge failed
Command line hint
To perform the merge from the command line, you could do something like the following (where "origin" is the name of the remote in your local git repo):