Merge main into feature/mynah-keyup-fix-beta#2690
Open
aws-toolkit-automation wants to merge 52 commits into
Open
Merge main into feature/mynah-keyup-fix-beta#2690aws-toolkit-automation wants to merge 52 commits into
aws-toolkit-automation wants to merge 52 commits into
Conversation
* perf(amazonq): cap context command payload and throttle indexing updates - Cap context commands sent to webview at 10,000 items - Throttle onIndexingInProgressChanged with 500ms coalescing - Cache full item list before applying cap for reuse - Add preservation property-based tests - Update unit tests for throttle behavior * chore: error * fix: newly added files are not be loaded * fix: bugfix * perf: handle context commands in server * perf: add server-side filtering for context commands in large repos * chore: bump language-server-runtimes, runtimes-types, and mynah-ui * chore: remove redundant debug log * fix: filter out externally deleted files from context command results Files deleted outside the IDE (e.g. git revert/checkout) were not removed from the cached context commands because LSP workspace file operation events only fire for IDE-initiated deletions. Add an fs.existsSync check when returning results to the client so stale entries are excluded regardless of how the file was removed. * chore: remove debug logs from context commands and indexing paths * fix: scope filterContextCommandsResponse to requesting tab Previously, filter responses updated contextCommands in all tabs, causing a search in one tab to overwrite the default list in others. Track the originating tabId and scope the store update accordingly. * fix: address PR review feedback for context command filtering
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
* chore: bump agentic version: 1.64.0 * fix: reserve folder budget in initial context command cap (#2693) * fix: reserve folder budget in initial context command cap The initial sendContextCommands push is capped at 1000 items, but the flat slice(0, 1000) starves folders when files dominate the list. In large repos (212k+ items), the first 1000 are almost all files, so @folder shows no children until the user types a search term. Partition items by type and reserve 10% of the cap budget for folders before filling the rest with files and code symbols. This ensures @folder always has children on first load. The filter handler already searches the full uncapped cache, so this only affects the initial push. * test: add folder budget tests for processContextCommandUpdate Verify that the initial context command cap reserves slots for folders: - folders are included when items exceed the cap - all folders included when fewer than budget - total items don't exceed CONTEXT_COMMAND_PAYLOAD_CAP - small payloads pass through unchanged * fix: apply cap to empty-search filter response to preserve @folder When onFilterContextCommands fires with an empty searchTerm (user navigated back or cleared search), the handler was returning ALL cached items (212k+) with no cap. This massive response overwrote the tab's contextCommands store, and subsequent @folder clicks showed an empty list because the store structure was inconsistent. Apply the same cap+budget logic as processContextCommandUpdate so the empty-search response matches the initial push structure. * refactor: remove stale context command cache, always pull fresh from indexer The cachedContextCommands field was a separate copy of the indexer's data that could get out of sync — causing @folder to show empty after searches overwrote the store, and stale items to persist after file operations. Remove the cache entirely. The indexer (local-indexing) is the single source of truth. The filter handler now calls getFreshItems() on every request, and processContextCommandUpdate receives items directly from the indexer callbacks. The cap+budget logic is extracted into capItems() and shared between the initial push and the empty-search filter path. * fix: restore base context commands on empty filter instead of round-tripping After a search filtered the context commands, the store held the filtered set. Subsequent @Folder/@file clicks read from this stale store and showed only the previous search results. When onContextCommandFilter fires with an empty searchTerm (user cleared search or navigated back), restore contextCommandGroups directly to the store instead of sending a request to the server. This keeps the store consistent with the base set and avoids the round-trip latency. * fix: prevent sendContextCommands from resetting active filter tab sendContextCommands is a server push that fires on indexing changes and overwrites contextCommands for ALL tabs. This reset the picker while the user was browsing @Folder/@file sub-menus, causing the 6-10 second snap-back to the main menu. Skip the store update for tabs with an active filter session (lastFilterTabId). Clear the guard on tab change, tab remove, and chat prompt submission so it doesn't persist. * fix: restore base contextCommands after filter response via microtask filterContextCommandsResponse updates the store with filtered results so the picker's store listener can refresh. But this left the store with stale filtered data, causing @Folder/@file to show previous search results on subsequent navigation. After updating the store for the picker, schedule a microtask to restore contextCommandGroups (the base set) back to the store. The picker captures filtered items synchronously during updateStore, so the microtask restore doesn't affect the current display but ensures sub-menu navigation reads from the full base set. * fix: restore filterContextCommandsResponse store update Now that mynah-ui preserves baseContextCommands separately from the store's contextCommands, the filter response can safely update the store again. The picker uses the filtered data for display while sub-menu navigation reads from the base snapshot. * chore: patch * test: cover getFreshItems and registerFilterHandler empty-search - 3 tests for getFreshItems: getInstance reject, getContextCommandItems reject, success path. - 2 tests for registerFilterHandler empty-search path: applies capItems folder budget when called with empty searchTerm and when called with a whitespace-only searchTerm. * fix: reserve code symbol budget in capItems The previous capItems partitioned items into folders vs nonFolders, where nonFolders included both files AND code symbols sharing the same 900-slot budget. In file-heavy repos (e.g. Linux kernel: 212k+ items) files dominate the input order so code symbols are silently dropped from the initial picker view, even though typing a search term still finds them via the non-empty filter path. Replace the 2-way partition with a 3-way 10/10/80 split (folders / code / files). Slack from an under-filled folder or code budget flows into the file budget via the subtraction below. Mirrors the existing folder-budget fix pattern. Add 5 tests: - code symbols included when items exceed cap - all code symbols preserved when fewer than budget - 100/100/800 split when all three categories overflow - code not starved when files come first in input (regression case) - empty-search filter handler also reserves the code budget * fix: bump context command payload cap from 1000 to 2000 Double both CONTEXT_COMMAND_PAYLOAD_CAP and MAX_FILTER_RESULTS so the initial picker view and the typed-search filter response can return up to 2000 items each. The 10/10/80 budget split now yields 200 folders / 200 code / 1600 files instead of 100 / 100 / 800. The bottleneck under load is fs.existsSync over the full ~212k indexer item set, not the cap; doubling the cap adds <50KB to the LSP payload and a few ms to map/render but is otherwise negligible. mynah-ui's DetailedListWrapper virtualizes by visible block, so 2x items don't add proportional render cost. Update all 8 affected test assertions to the new expected counts. * chore: bump @aws/mynah-ui to ^4.40.1 Pulls in the latest mynah-ui patch release. See https://github.com/aws/mynah-ui/releases/tag/v4.40.1 * fix: switch capItems split to 500/500/1000 (25/25/50) Folders and code symbols each get 25% of the cap (500), files get 50% (1000). Previously the 10/10/80 split (200/200/1600) tilted heavily toward files; the new split gives folders and code symbols a fair share of the initial picker view in folder- and symbol-rich repos. This only affects the **empty-search** picker view (no search term). The non-empty filter path still scores against the full fresh indexer set in registerFilterHandler — typing a search term will find any folder, file, or code symbol regardless of whether it fit into the cap. Test inputs scaled up to 600-800 per category so the new 500-slot budget is actually exercised. All 24 tests pass. * test: drop stale cachedContextCommands assertion in preservation test The property-based test 'processContextCommandUpdate sends all items and caches them for small payloads' has been failing in CI since commit 79e6e75 (refactor: remove stale context command cache, always pull fresh from indexer). That refactor deleted the cachedContextCommands field, but this preservation test still asserted that (provider as any).cachedContextCommands === items, which now always evaluates to undefined !== items and fails on the empty-array counterexample. Drop the cache assertion. The test now verifies the still-meaningful contract: processContextCommandUpdate dispatches exactly one sendContextCommands call with a contextCommandGroups payload. Local repro: npx mocha --require ts-node/register 'src/language-server/agenticChat/context/contextCommandsProvider*.test.ts' → 28 passing. --------- Co-authored-by: aws-toolkit-automation <>
…on (#2695) Add null check for workspaceFolderManager at the top of updateConfiguration() to prevent TypeError when didChangeConfiguration fires before onInitialized completes. Also add diagnostic logging for config update flow. Context: V2160933004
…ring in context (#2698) * fix: remove @workspace from context commands menu (#2669) * fix: clean up @workspace dead code after removing from context menu (#2670) * fix: remove @workspace from context commands menu * fix: clean up @workspace dead code after removing from context menu * fix: remove onIndexingInProgressChanged test * chore: remove remaining @workspace / vector search dead code (#2687) Remove all code paths related to @workspace (vector/semantic search) that were left after the initial UI removal. This includes: - localProjectContextController: remove queryVectorIndex, isIndexingEnabled, enableIndexing, GPU/worker thread/cache dir config, onIndexingInProgressChanged, buildIndex('all'). buildIndex now always uses 'default' (repomap only). - configurationUtils: remove enableLocalIndexing, enableGpuAcceleration, indexWorkerThreads, indexCacheDirPath from config types and defaults - localProjectContextServer: remove dead config params passed to init() - triggerContext: remove extractProjectContext and @workspace check - chatTelemetryController/telemetryService: remove cwsprChatHasWorkspaceContext - Delete codeSearch.ts (never registered in toolServer, always dead code) - Update corresponding test files * fix: typed `@folder` context not showing files in collapsible list + fix merge conflicts (#2696) * perf(amazonq): context command performance (#2682) * perf(amazonq): cap context command payload and throttle indexing updates - Cap context commands sent to webview at 10,000 items - Throttle onIndexingInProgressChanged with 500ms coalescing - Cache full item list before applying cap for reuse - Add preservation property-based tests - Update unit tests for throttle behavior * chore: error * fix: newly added files are not be loaded * fix: bugfix * perf: handle context commands in server * perf: add server-side filtering for context commands in large repos * chore: bump language-server-runtimes, runtimes-types, and mynah-ui * chore: remove redundant debug log * fix: filter out externally deleted files from context command results Files deleted outside the IDE (e.g. git revert/checkout) were not removed from the cached context commands because LSP workspace file operation events only fire for IDE-initiated deletions. Add an fs.existsSync check when returning results to the client so stale entries are excluded regardless of how the file was removed. * chore: remove debug logs from context commands and indexing paths * fix: scope filterContextCommandsResponse to requesting tab Previously, filter responses updated contextCommands in all tabs, causing a search in one tab to overwrite the default list in others. Track the originating tabId and scope the store update accordingly. * fix: address PR review feedback for context command filtering * fix: correct URI mapping in onDidRenameFiles handler (#2688) * chore(release): release packages from branch main (#2689) Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> * chore: merge agentic version 1.64.0 (#2694) * chore: bump agentic version: 1.64.0 * fix: reserve folder budget in initial context command cap (#2693) * fix: reserve folder budget in initial context command cap The initial sendContextCommands push is capped at 1000 items, but the flat slice(0, 1000) starves folders when files dominate the list. In large repos (212k+ items), the first 1000 are almost all files, so @folder shows no children until the user types a search term. Partition items by type and reserve 10% of the cap budget for folders before filling the rest with files and code symbols. This ensures @folder always has children on first load. The filter handler already searches the full uncapped cache, so this only affects the initial push. * test: add folder budget tests for processContextCommandUpdate Verify that the initial context command cap reserves slots for folders: - folders are included when items exceed the cap - all folders included when fewer than budget - total items don't exceed CONTEXT_COMMAND_PAYLOAD_CAP - small payloads pass through unchanged * fix: apply cap to empty-search filter response to preserve @folder When onFilterContextCommands fires with an empty searchTerm (user navigated back or cleared search), the handler was returning ALL cached items (212k+) with no cap. This massive response overwrote the tab's contextCommands store, and subsequent @folder clicks showed an empty list because the store structure was inconsistent. Apply the same cap+budget logic as processContextCommandUpdate so the empty-search response matches the initial push structure. * refactor: remove stale context command cache, always pull fresh from indexer The cachedContextCommands field was a separate copy of the indexer's data that could get out of sync — causing @folder to show empty after searches overwrote the store, and stale items to persist after file operations. Remove the cache entirely. The indexer (local-indexing) is the single source of truth. The filter handler now calls getFreshItems() on every request, and processContextCommandUpdate receives items directly from the indexer callbacks. The cap+budget logic is extracted into capItems() and shared between the initial push and the empty-search filter path. * fix: restore base context commands on empty filter instead of round-tripping After a search filtered the context commands, the store held the filtered set. Subsequent @Folder/@file clicks read from this stale store and showed only the previous search results. When onContextCommandFilter fires with an empty searchTerm (user cleared search or navigated back), restore contextCommandGroups directly to the store instead of sending a request to the server. This keeps the store consistent with the base set and avoids the round-trip latency. * fix: prevent sendContextCommands from resetting active filter tab sendContextCommands is a server push that fires on indexing changes and overwrites contextCommands for ALL tabs. This reset the picker while the user was browsing @Folder/@file sub-menus, causing the 6-10 second snap-back to the main menu. Skip the store update for tabs with an active filter session (lastFilterTabId). Clear the guard on tab change, tab remove, and chat prompt submission so it doesn't persist. * fix: restore base contextCommands after filter response via microtask filterContextCommandsResponse updates the store with filtered results so the picker's store listener can refresh. But this left the store with stale filtered data, causing @Folder/@file to show previous search results on subsequent navigation. After updating the store for the picker, schedule a microtask to restore contextCommandGroups (the base set) back to the store. The picker captures filtered items synchronously during updateStore, so the microtask restore doesn't affect the current display but ensures sub-menu navigation reads from the full base set. * fix: restore filterContextCommandsResponse store update Now that mynah-ui preserves baseContextCommands separately from the store's contextCommands, the filter response can safely update the store again. The picker uses the filtered data for display while sub-menu navigation reads from the base snapshot. * chore: patch * test: cover getFreshItems and registerFilterHandler empty-search - 3 tests for getFreshItems: getInstance reject, getContextCommandItems reject, success path. - 2 tests for registerFilterHandler empty-search path: applies capItems folder budget when called with empty searchTerm and when called with a whitespace-only searchTerm. * fix: reserve code symbol budget in capItems The previous capItems partitioned items into folders vs nonFolders, where nonFolders included both files AND code symbols sharing the same 900-slot budget. In file-heavy repos (e.g. Linux kernel: 212k+ items) files dominate the input order so code symbols are silently dropped from the initial picker view, even though typing a search term still finds them via the non-empty filter path. Replace the 2-way partition with a 3-way 10/10/80 split (folders / code / files). Slack from an under-filled folder or code budget flows into the file budget via the subtraction below. Mirrors the existing folder-budget fix pattern. Add 5 tests: - code symbols included when items exceed cap - all code symbols preserved when fewer than budget - 100/100/800 split when all three categories overflow - code not starved when files come first in input (regression case) - empty-search filter handler also reserves the code budget * fix: bump context command payload cap from 1000 to 2000 Double both CONTEXT_COMMAND_PAYLOAD_CAP and MAX_FILTER_RESULTS so the initial picker view and the typed-search filter response can return up to 2000 items each. The 10/10/80 budget split now yields 200 folders / 200 code / 1600 files instead of 100 / 100 / 800. The bottleneck under load is fs.existsSync over the full ~212k indexer item set, not the cap; doubling the cap adds <50KB to the LSP payload and a few ms to map/render but is otherwise negligible. mynah-ui's DetailedListWrapper virtualizes by visible block, so 2x items don't add proportional render cost. Update all 8 affected test assertions to the new expected counts. * chore: bump @aws/mynah-ui to ^4.40.1 Pulls in the latest mynah-ui patch release. See https://github.com/aws/mynah-ui/releases/tag/v4.40.1 * fix: switch capItems split to 500/500/1000 (25/25/50) Folders and code symbols each get 25% of the cap (500), files get 50% (1000). Previously the 10/10/80 split (200/200/1600) tilted heavily toward files; the new split gives folders and code symbols a fair share of the initial picker view in folder- and symbol-rich repos. This only affects the **empty-search** picker view (no search term). The non-empty filter path still scores against the full fresh indexer set in registerFilterHandler — typing a search term will find any folder, file, or code symbol regardless of whether it fit into the cap. Test inputs scaled up to 600-800 per category so the new 500-slot budget is actually exercised. All 24 tests pass. * test: drop stale cachedContextCommands assertion in preservation test The property-based test 'processContextCommandUpdate sends all items and caches them for small payloads' has been failing in CI since commit 79e6e75 (refactor: remove stale context command cache, always pull fresh from indexer). That refactor deleted the cachedContextCommands field, but this preservation test still asserted that (provider as any).cachedContextCommands === items, which now always evaluates to undefined !== items and fails on the empty-array counterexample. Drop the cache assertion. The test now verifies the still-meaningful contract: processContextCommandUpdate dispatches exactly one sendContextCommands call with a contextCommandGroups payload. Local repro: npx mocha --require ts-node/register 'src/language-server/agenticChat/context/contextCommandsProvider*.test.ts' → 28 passing. --------- Co-authored-by: aws-toolkit-automation <> * fix: typed @folder context not showing files in collapsible list When typing @folder (non-pinned), the expanded file entries were not appearing in the context list. The ordering logic looked up the folder path in docMap, but docMap is keyed by individual file paths. Added a fallback for folder items that matches all child file entries by path prefix. Pinned @folder was unaffected because it bypasses the docMap lookup. * chore: fix prettier formatting --------- Co-authored-by: Will Lo <96078566+Will-ShaoHua@users.noreply.github.com> Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> * fix: rebuild qserver zips with stripped indexing library (#2672) Remove ONNX, faiss, and CodeSage model from qserver bundles. The indexing library no longer contains vector/semantic search code since @workspace is being removed. Each qserver zip drops from ~100MB to ~2.9MB. @file, @folder, @code continue to work (tree-sitter + BM25). All 5 platform zips are now identical (no native binaries). --------- Co-authored-by: Will Lo <96078566+Will-ShaoHua@users.noreply.github.com> Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: aws-toolkit-automation <43144436+aws-toolkit-automation@users.noreply.github.com>
…2708) * feat(amazonq): add consent prompt for workspace-scoped MCP servers * fix(amazonq): suppress MCP consent re-prompts within session on deny (#2703) * test: add consent gate tests for workspace-scoped MCP servers (#2705) * fix: add missing closing brace in mcpManager.test.ts * fix: use getGlobalMcpConfigPath for cross-platform path in consent gate test * fix: addressing review feedback --------- Co-authored-by: Aseem Sharma <aseemxs@amazon.com> Co-authored-by: Aseem sharma <198968351+aseemxs@users.noreply.github.com>
* feat(amazonq): add consent prompt for workspace-scoped MCP servers * fix(amazonq): suppress MCP consent re-prompts within session on deny (#2703) * test: add consent gate tests for workspace-scoped MCP servers (#2705) * fix: add missing closing brace in mcpManager.test.ts * fix: use getGlobalMcpConfigPath for cross-platform path in consent gate test * fix: addressing review feedback * fix(amazonq): improve MCP consent gate reliability and cleanup - Fix spurious re-prompts on IDE reload by using OR matching in hasApproval: match on (serverName, fingerprint) OR (serverName, workspaceHash). The fingerprint can change slightly between reloads due to config migration, and the workspaceHash covers that case. - Add getGlobalPersonaConfigPath to the trusted set so persona configs don't trigger unnecessary consent prompts. - Clear sessionDeniedConsent in close() for consistency with other state. - Replace non-null assertion with inline Set initialization. - Evict stale approval entries when config changes for the same server and workspace instead of accumulating them. - Normalize configPath via normalizePathFromUri before consent checks. - Add removeApproval and call it from removeServer so deleting a workspace MCP server clears its persisted approval. - Improve prompt text to explain persistence semantics to the user. - Normalize paths with path.resolve and forward slashes for cross- platform consistency in fingerprintWorkspace. --------- Co-authored-by: Aseem Sharma <aseemxs@amazon.com> Co-authored-by: Aseem sharma <198968351+aseemxs@users.noreply.github.com>
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
…PI selection (#2713) (#2714) The onInlineChatPrompt handler was hardcoded to call client.sendMessage() regardless of the authentication type. This caused Kiro Enterprise subscription users on Eclipse to get Your subscription does not support this application errors because SendMessage is not in the Kiro Enterprise API allowlist. Route inline chat through getChatResponse() which correctly selects GenerateAssistantResponse for token-based (SSO/IdC) clients and SendMessage only for IAM clients, matching the behavior of regular chat.
Co-authored-by: aws-toolkit-automation <>
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: aws-toolkit-automation <>
* feat(netTransform): add workspace description support to createWorkspace * feat(netTransform): add debug logging for createWorkspace request * feat(netTransform): include workspace description in listWorkspaces response * fix(netTransform): include description when adding new workspace to list * feat(netTransform): add ListJobs API * feat(netTransform): add debug logging to ListJobs * fix(netTransform): register ListJobs command * fix(netTransform): add ClientSource to ListJobs response * updated objective data * fix(netTransform): treat CREATED with failureReason as FAILED * debug: add logging for job status and failureReason * revert: remove speculative stuck job logic, keep ClientSource * feat(netTransform): add pagination to ListJobs to fetch all jobs * feat: added setting breakpoint functionality * feat: added setting breakpoint functionality * fix: renamed breakpont to checkpoint * feat: add applicationUrl to ListWorkspaces response * refactor: atx get plan now returns in its own class definition * Fix: Extract workspaces array from listWorkspaces result * feat: added ability to handle step hitls for checkpointing * fix: changed step hitl folder * fix: changed plan detection and changed model name to match toolkit * feat: added handling checkpoint for user action * feat: added polling for step hitl task to close * feat: added step artifact download and extract capability * fix: fixed step status check for artifact download * feat: added apply changes capabilities * fix: get checkpoints during HITL * feat: adding chat apis commands to FES for transform * feat: added chatty agent support * fix: updated elastic gumby client * fix: updated job status to EXECUTING and addes metadata for file changes * fix: increasing wait time to 5 mins for chat messages * fix: increasing wait time to 15 mins for chat messages * feat: added 2 way sync * fix: downloads diff for all interactive modes * feat: added 2 way sync capability * fix: changed from submit to update hitl * fix: added inprogress status for stephitl * feat: add artifactdownload and listartifact command * fix: download artifact as zip without extracting * fix: remove excessive logging * fix: update hitl with empty file changes * fix: fixing hard coded job status for transform * fix: excluded artifacts from listartifacts for download with no file names * fix: removed unnecessary hitl handling * feat: adding timestamp to worklogs * feat: add job dashboard and report download commands with per-repo and job-level reports * fix: add missing closing brace in AtxDownloadArtifactResponse * fix: downloaded file names * fix: download artifacts * fix: allows list messages to accept timestamp as strings * feat: adding hitl for build verification * added command for uploading custom plan * updated the chatty agent id * fix: removed on failure mode, combined with interactive * fix: hitl for dotnet build * fix: changed check for completed step to depth 2 steps only * fix: hitl for dotnet build * fix: hitl artifact fix * fix: hitls with non zip artifacts * feat: added support to upload any file (#2707) Co-authored-by: Zhengan Pan <zhenganp@amazon.com> * feat: add local build verification LSP bridge for build/fix loop (#2715) - Add CompleteLocalBuildHitl request/response types in atxModels - Add completeLocalBuildHitl command handler in atxNetTransformServer - Update atxTransformHandler with downloadCompletedStepArtifacts pipeline: polls for SUCCEEDED depth-2 steps, downloads checkpoint ZIPs, extracts diffs and metadata, applies file changes to customer source tree - Add HITL probe logging during EXECUTING state for diagnostic visibility - Log orchestrator agent override when ATX_ORCHESTRATOR_AGENT env var is set Co-authored-by: Aman Prakash <apaman@amazon.com> * fix: fixing write lock on worklogs json (#2720) Co-authored-by: pranavfi <pranavfi@amazon.com> * feat: add retry logic and error notification for diff apply failures * feat: add backward compatibility for prod IDE via handler routing (#2722) * feat: add backward compatibility for prod IDE via handler routing * fix: route handlers per-request to survive lsp reinit * fix: fixed the transformation hub status (#2725) * feat: Karsraja atx handler coverage (#2723) * test(amazonq): add unit tests for atx getTransformInfo * test(amazonq): add unit tests for atx getTransformationPlan and tree helpers * test(amazonq): add unit tests for atx updateWorkspace and applyChanges * test(amazonq): add unit tests for atx setCheckpoints, getHitlAgentArtifact and getJobDashboard * test(amazonq): add unit tests for atx startTransform and lifecycle helpers * test(amazonq): add unit tests for atx workspace, job, artifact and hitl helpers * test(amazonq): add unit tests for atx upload flows, polling and small wrappers * test(amazonq): add unit tests for atx hitl state branches and fs helpers * test(amazonq): add unit tests for atx private helpers and edge cases * test(amazonq): add edge-case unit tests to push atx coverage past 82% * fix(amazonq): annotate test baseRequest literals as any to satisfy strict tsc * test(amazonq): add routing tests for atx server per-request handler dispatch --------- Co-authored-by: Jordan Miao <gzmiao@amazon.com> Co-authored-by: Pranav Firake <pranavfi@amazon.com> Co-authored-by: Zhengan Pan <zhenganp@amazon.com> Co-authored-by: aws-toolkit-automation <43144436+aws-toolkit-automation@users.noreply.github.com> Co-authored-by: Aman Prakash <56380782+amanprak@users.noreply.github.com> Co-authored-by: Aman Prakash <apaman@amazon.com> Co-authored-by: Pranav Firake <pranav.firake7@gmail.com>
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: aws-toolkit-automation <>
…2718) (#2730) Add error handling to onFileClicked to catch exceptions from showDocument when the target file doesn't exist. Fix resolveAbsolutePath to verify the file exists in the prompts directory before returning the path, preventing incorrect fallback for .md files created by fsWrite. Use description as fullPath fallback in the chat-client file list mapping so fsWrite file links resolve correctly without duplicating path data. Fixes: aws/amazon-q-vscode#59 Co-authored-by: aws-toolkit-automation <43144436+aws-toolkit-automation@users.noreply.github.com>
* fix: add postMessage origin check to prevent cross-origin XSS Reject messages whose origin does not match window.location.origin in handleInboundMessage. Without this check, a malicious page could send crafted postMessage events to the chat iframe and achieve DOM XSS/RCE. All supported host environments (VS Code, JetBrains, Visual Studio webviews, SageMaker JupyterLab) deliver messages same-origin, so legitimate traffic is unaffected. Ref: P389799154 * fix: clean up message event listeners between tests Each beforeEach was adding a new message handler via createChat() without removing the previous one. Stale handlers piled up and all fired on dispatchEvent, causing the generic command test to timeout under CI load (multiple handlers triggering handleChatPrompt simultaneously). Now afterEach removes the handler registered during that test's setup. --------- Co-authored-by: Boyu <bywang@amazon.com>
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
…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 <>
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
12 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):