Merge commit '2b44ec5c3fcd5788a7fb6abaa231c6659018babc' into joao/copilot-builtin

.github/copilot-instructions.md

@@ -145,6 +145,7 @@ function f(x: number, y: string): void { }
 - You MUST NOT use storage keys of another component only to make changes to that component. You MUST come up with proper API to change another component.
 - Use `IEditorService` to open editors instead of `IEditorGroupsService.activeGroup.openEditor` to ensure that the editor opening logic is properly followed and to avoid bypassing important features such as `revealIfOpened` or `preserveFocus`.
 - Avoid using `bind()`, `call()` and `apply()` solely to control `this` or partially apply arguments; prefer arrow functions or closures to capture the necessary context, and use these methods only when required by an API or interoperability.
+- Avoid using events to drive control flow between components. Instead, prefer direct method calls or service interactions to ensure clearer dependencies and easier traceability of logic. Events should be reserved for broadcasting state changes or notifications rather than orchestrating behavior across components.
 
 ## Learnings
 - Minimize the amount of assertions in tests. Prefer one snapshot-style `assert.deepStrictEqual` over multiple precise assertions, as they are much more difficult to understand and to update.

.github/instructions/remoteAgentHost.instructions.md

@@ -0,0 +1,35 @@
+---
+description: Architecture documentation for remote agent host connections. Use when working in `src/vs/sessions/contrib/remoteAgentHost`
+applyTo: src/vs/sessions/contrib/remoteAgentHost/**
+---
+
+# Remote Agent Host
+
+The remote agent host feature connects the sessions app to agent host processes running on other machines over WebSocket.
+
+## Key Files
+
+- `ARCHITECTURE.md` - full architecture documentation (URI conventions, registration flow, data flow diagram)
+- `REMOTE_AGENT_HOST_RECONNECTION.md` - reconnection lifecycle spec (15 numbered requirements)
+- `browser/remoteAgentHost.contribution.ts` - central orchestrator
+- `browser/agentHostFileSystemProvider.ts` - read-only FS provider for remote browsing
+
+## Architecture Documentation
+
+When making changes to this feature area, **review and update `ARCHITECTURE.md`** if your changes affect:
+
+- Connection lifecycle (connect, disconnect, reconnect)
+- Agent registration flow
+- URI conventions or naming
+- Session creation flow
+- The data flow diagram
+
+The doc lives at `src/vs/sessions/contrib/remoteAgentHost/ARCHITECTURE.md`.
+
+## Related Code Outside This Folder
+
+- `src/vs/platform/agentHost/common/remoteAgentHostService.ts` - service interface (`IRemoteAgentHostService`)
+- `src/vs/platform/agentHost/electron-browser/remoteAgentHostServiceImpl.ts` - Electron implementation
+- `src/vs/platform/agentHost/electron-browser/remoteAgentHostProtocolClient.ts` - WebSocket protocol client
+- `src/vs/workbench/contrib/chat/browser/agentSessions/agentHost/agentHostSessionListController.ts` - session list sidebar
+- `src/vs/workbench/contrib/chat/browser/agentSessions/agentHost/agentHostSessionHandler.ts` - session content provider

.github/prompts/fix-error.prompt.md

@@ -23,15 +23,32 @@ After the fix is validated (compilation clean, tests pass):
 1. **Create a branch**: `git checkout -b <github-username>/<short-description>` (e.g., `bryanchen-d/fix-notebook-index-error`).
 2. **Commit**: Stage changed files and commit with a message like `fix: <brief description> (#<issue-number>)`.
 3. **Push**: `git push -u origin <branch-name>`.
-4. **Create a draft PR** with a description that includes:
-   - A summary of the change.
-   - What scenarios may trigger the error.
-   - The code flow explaining why the error gets thrown and goes unhandled.
-   - Steps a user can follow to manually validate the fix.
-   - How the fix addresses the issue, with a brief note per changed file.
-5. **Monitor the PR** for Copilot review comments. Wait 1-2 minutes after each push for Copilot to leave its review, then check for new comments. Evaluate each comment:
-   - If valid, apply the fix, amend the commit, and force-push.
-   - If not applicable, leave a reply explaining why.
-   - After addressing comments, update the PR description if the changes affect the summary, code flow explanation, or per-file notes.
-6. **Repeat monitoring** after each force-push: wait 1-2 minutes, check for new Copilot comments, and address them. Continue this loop until no new comments appear.
-7. **Re-run tests** after addressing review comments to confirm nothing regressed.
+4. **Create a draft PR** with a description that includes these sections:
+   - **Summary**: A concise description of what was changed and why.
+   - **Issue link**: `Fixes #<issue-number>` so GitHub auto-closes the issue when the PR merges.
+   - **Trigger scenarios**: What user actions or system conditions cause this error to surface.
+   - **Code flow diagram**: A Mermaid swimlane/sequence diagram showing the call chain from trigger to error. Use participant labels for the key components (e.g., classes, modules, processes). Example:
+     ````
+     ```mermaid
+     sequenceDiagram
+         participant A as CallerComponent
+         participant B as MiddleLayer
+         participant C as LowLevelUtil
+         A->>B: someOperation(data)
+         B->>C: validate(data)
+         C-->>C: data is invalid
+         C->>B: throws "error message"
+         B->>A: unhandled error propagates
+     ```
+     ````
+   - **Manual validation steps**: Concrete, step-by-step instructions a reviewer can follow to reproduce the original error and verify the fix. Include specific setup requirements (e.g., file types to open, settings to change, actions to perform). If the error cannot be easily reproduced manually, explain why and describe what alternative validation was performed (e.g., unit tests, code inspection).
+   - **How the fix works**: A brief explanation of the fix approach, with a note per changed file.
+5. **Monitor the PR — BLOCKING**: You MUST NOT complete the task until the monitoring loop below is done.
+   - Wait 2 minutes after each push, then check for Copilot review comments using `gh pr view <number> --json reviews,comments` and `gh api repos/{owner}/{repo}/pulls/{number}/comments`.
+   - If there are review comments, evaluate each one:
+     - If valid, apply the fix in a new commit, push, and **resolve the comment thread** using the GitHub GraphQL API (`resolveReviewThread` mutation with the thread's node ID).
+     - If not applicable, leave a reply explaining why.
+     - After addressing comments, update the PR description if the changes affect the summary, diagram, or per-file notes.
+   - **Re-run tests** after addressing review comments to confirm nothing regressed.
+   - After each push, repeat the wait-and-check cycle. Continue until **two consecutive checks return zero new comments**.
+6. **Verify CI**: After the monitoring loop is done, check that CI checks are passing using `gh pr checks <number>`. If any required checks fail, investigate and fix. Do NOT complete the task with failing CI.

.github/skills/chat-customizations-editor/SKILL.md

@@ -0,0 +1,42 @@
+---
+name: chat-customizations-editor
+description: Use when working on the Chat Customizations editor — the management UI for agents, skills, instructions, hooks, prompts, MCP servers, and plugins.
+---
+
+# Chat Customizations Editor
+
+Split-view management pane for AI customization items across workspace, user, extension, and plugin storage. Supports harness-based filtering (Local, Copilot CLI, Claude).
+
+## Spec
+
+**`src/vs/sessions/AI_CUSTOMIZATIONS.md`** — always read before making changes, always update after.
+
+## Key Folders
+
+| Folder | What |
+|--------|------|
+| `src/vs/workbench/contrib/chat/common/` | `ICustomizationHarnessService`, `ISectionOverride`, `IStorageSourceFilter` — shared interfaces and filter helpers |
+| `src/vs/workbench/contrib/chat/browser/aiCustomization/` | Management editor, list widgets (prompts, MCP, plugins), harness service registration |
+| `src/vs/sessions/contrib/chat/browser/` | Sessions-window overrides (harness service, workspace service) |
+| `src/vs/sessions/contrib/sessions/browser/` | Sessions tree view counts and toolbar |
+
+When changing harness descriptor interfaces or factory functions, verify both core and sessions registrations compile.
+
+## Key Interfaces
+
+- **`IHarnessDescriptor`** — drives all UI behavior declaratively (hidden sections, button overrides, file filters, agent gating). See spec for full field reference.
+- **`ISectionOverride`** — per-section button customization (command invocation, root file creation, type labels, file extensions).
+- **`IStorageSourceFilter`** — controls which storage sources and user roots are visible per harness/type.
+
+Principle: the UI widgets read everything from the descriptor — no harness-specific conditionals in widget code.
+
+## Testing
+
+Component explorer fixtures (see `component-fixtures` skill): `aiCustomizationListWidget.fixture.ts`, `aiCustomizationManagementEditor.fixture.ts` under `src/vs/workbench/test/browser/componentFixtures/`.
+
+```bash
+./scripts/test.sh --grep "applyStorageSourceFilter|customizationCounts"
+npm run compile-check-ts-native && npm run valid-layers-check
+```
+
+See the `sessions` skill for sessions-window specific guidance.

.github/skills/fix-ci-failures/SKILL.md

@@ -0,0 +1,269 @@
+---
+name: fix-ci-failures
+description: Investigate and fix CI failures on a pull request. Use when CI checks fail on a PR branch — covers finding the PR, identifying failed checks, downloading logs and artifacts, extracting the failure cause, and iterating on a fix. Requires the `gh` CLI.
+---
+
+# Investigating and Fixing CI Failures
+
+This skill guides you through diagnosing and fixing CI failures on a PR using the `gh` CLI. The user has the PR branch checked out locally.
+
+## Workflow Overview
+
+1. Identify the current branch and its PR
+2. Check CI status and find failed checks
+3. Download logs for failed jobs
+4. Extract and understand the failure
+5. Fix the issue and push
+
+---
+
+## Step 1: Identify the Branch and PR
+
+```bash
+# Get the current branch name
+git branch --show-current
+
+# Find the PR for this branch
+gh pr view --json number,title,url,statusCheckRollup
+```
+
+If no PR is found, the user may need to specify the PR number.
+
+---
+
+## Step 2: Check CI Status
+
+```bash
+# List all checks and their status (pass/fail/pending)
+gh pr checks --json name,state,link,bucket
+
+# Filter to only failed checks
+gh pr checks --json name,state,link,bucket --jq '.[] | select(.bucket == "fail")'
+```
+
+The `link` field contains the URL to the GitHub Actions job. Extract the **run ID** from the URL — it's the number after `/runs/`:
+```
+https://github.com/microsoft/vscode/actions/runs/<RUN_ID>/job/<JOB_ID>
+```
+
+If checks are still `IN_PROGRESS`, wait for them to complete before downloading logs:
+```bash
+gh pr checks --watch --fail-fast
+```
+
+---
+
+## Step 3: Get Failed Job Details
+
+```bash
+# List failed jobs in a run (use the run ID from the check link)
+gh run view <RUN_ID> --json jobs --jq '.jobs[] | select(.conclusion == "failure") | {name: .name, id: .databaseId}'
+```
+
+---
+
+## Step 4: Download Failure Logs
+
+There are two approaches depending on the type of failure.
+
+### Option A: View Failed Step Logs Directly
+
+Best for build/compile/lint failures where the error is in the step output:
+
+```bash
+# View only the failed step logs (most useful — shows just the errors)
+gh run view <RUN_ID> --job <JOB_ID> --log-failed
+```
+
+> **Important**: `--log-failed` requires the **entire run** to complete, not just the failed job. If other jobs are still running, this command will block or error. Use **Option C** below to get logs for a completed job while the run is still in progress.
+
+The output can be large. Pipe through `tail` or `grep` to focus:
+```bash
+# Last 100 lines of failed output
+gh run view <RUN_ID> --job <JOB_ID> --log-failed | tail -100
+
+# Search for common error patterns
+gh run view <RUN_ID> --job <JOB_ID> --log-failed | grep -E "Error|FAIL|error TS|AssertionError|failing"
+```
+
+### Option B: Download Artifacts
+
+Best for integration test failures where detailed logs (terminal logs, ext host logs, crash dumps) are uploaded as artifacts:
+
+```bash
+# List available artifacts for a run
+gh run download <RUN_ID> --pattern '*' --dir /dev/null 2>&1 || gh run view <RUN_ID> --json jobs --jq '.jobs[].name'
+
+# Download log artifacts for a specific failed job
+# Artifact naming convention: logs-<platform>-<arch>-<test-type>-<attempt>
+# Examples: logs-linux-x64-electron-1, logs-linux-x64-remote-1
+gh run download <RUN_ID> -n "logs-linux-x64-electron-1" -D /tmp/ci-logs
+
+# Download crash dumps if available
+gh run download <RUN_ID> -n "crash-dump-linux-x64-electron-1" -D /tmp/ci-crashes
+```
+
+> **Tip**: Use the test runner name from the failed check (e.g., "Linux / Electron" → `electron`, "Linux / Remote" → `remote`) and platform map ("Windows" → `windows-x64`, "Linux" → `linux-x64`, "macOS" → `macos-arm64`) to construct the artifact name.
+
+> **Warning**: Log artifacts may be empty if the test runner crashed before producing output (e.g., Electron download failure). In that case, fall back to **Option C**.
+
+### Option C: Download Per-Job Logs via API (works while run is in progress)
+
+When the run is still in progress but the failed job has completed, use the GitHub API to download that job's step logs directly:
+
+```bash
+# Save the full job log to a temp file (can be very large — 30k+ lines)
+gh api repos/microsoft/vscode/actions/jobs/<JOB_ID>/logs > "$TMPDIR/ci-job-log.txt"
+```
+
+Then search the saved file. **Start with `##[error]`** — this is the GitHub Actions error annotation that marks the exact line where the step failed:
+
+```bash
+# Step 1: Find the error annotation (fastest path to the failure)
+grep -n '##\[error\]' "$TMPDIR/ci-job-log.txt"
+
+# Step 2: Read context around the error (e.g., if error is on line 34371, read 200 lines before it)
+sed -n '34171,34371p' "$TMPDIR/ci-job-log.txt"
+```
+
+If `##[error]` doesn't reveal enough, use broader patterns:
+```bash
+# Find test failures, exceptions, and crash indicators
+grep -n -E 'HTTPError|ECONNRESET|ETIMEDOUT|502|exit code|Process completed|node:internal|triggerUncaughtException' "$TMPDIR/ci-job-log.txt" | head -20
+```
+
+> **Why save to a file?** The API response for a full job log can be 30k+ lines. Tool output gets truncated, so always redirect to a file first, then search.
+
+### VS Code Log Artifacts Structure
+
+Downloaded log artifacts typically contain:
+```
+logs-linux-x64-electron-1/
+  main.log              # Main process log
+  terminal.log          # Terminal/pty host log (key for run_in_terminal issues)
+  window1/
+    renderer.log        # Renderer process log
+    exthost/
+      exthost.log       # Extension host log (key for extension test failures)
+```
+
+Key files to examine first:
+- **Test assertion failures**: Check `exthost.log` for the extension host output and stack traces
+- **Terminal/sandbox issues**: Check `terminal.log` for rewriter pipeline, shell integration, and strategy logs
+- **Crash/hang**: Check `main.log` and look for crash dumps artifacts
+
+---
+
+## Step 5: Extract the Failure
+
+### For Test Failures
+
+Look for the test runner output in the failed step log:
+```bash
+# Find failing test names and assertion messages
+gh run view <RUN_ID> --job <JOB_ID> --log-failed | grep -A 5 "failing\|AssertionError\|Expected\|Unexpected"
+```
+
+Common patterns in VS Code CI:
+- **`AssertionError [ERR_ASSERTION]`**: Test assertion failed — check expected vs actual values
+- **`Extension host test runner exit code: 1`**: Integration test suite had failures
+- **`Command produced no output`**: Shell integration may not have captured command output (see terminal.log)
+- **`Error: Timeout`**: Test timed out — could be a hang or slow CI machine
+
+### For Build Failures
+
+```bash
+# Find TypeScript compilation errors
+gh run view <RUN_ID> --job <JOB_ID> --log-failed | grep "error TS"
+
+# Find hygiene/lint errors
+gh run view <RUN_ID> --job <JOB_ID> --log-failed | grep -E "eslint|stylelint|hygiene"
+```
+
+---
+
+## Step 6: Determine if Failures are Related to the PR
+
+Before fixing, determine if the failure is caused by the PR changes or is a pre-existing/infrastructure issue:
+
+1. **Check if the failing test is in code you changed** — if the test is in a completely unrelated area, it may be a flake
+2. **Check the test name** — does it relate to the feature area you modified?
+3. **Look at the failure output** — does it reference code paths your PR touches?
+4. **Check if the same tests fail on main** — if identical failures exist on recent main commits, it's a pre-existing issue
+5. **Look for infrastructure failures** — network timeouts, npm registry errors, and machine-level issues are not caused by code changes
+
+```bash
+# Check recent runs on main for the same workflow
+gh run list --branch main --workflow pr-linux-test.yml --limit 5 --json databaseId,conclusion,displayTitle
+```
+
+### Recognizing Infrastructure / Flaky Failures
+
+Not all CI failures are caused by code changes. Common infrastructure failures:
+
+**Network / Registry issues**:
+- `npm ERR! network`, `ETIMEDOUT`, `ECONNRESET`, `EAI_AGAIN` — npm registry unreachable
+- `error: RPC failed; curl 56`, `fetch-pack: unexpected disconnect` — git network failure
+- `Error: unable to get local issuer certificate` — TLS/certificate issues
+- `rate limit exceeded` — GitHub API rate limiting
+- `HTTPError: Request failed with status code 502` on `electron/electron/releases` — Electron CDN download failure (common in the `node.js integration tests` step, which downloads Electron at runtime)
+
+**Machine / Environment issues**:
+- `No space left on device` — CI disk full
+- `ENOMEM`, `JavaScript heap out of memory` — CI machine ran out of memory
+- `The runner has received a shutdown signal` — CI preemption / timeout
+- `Error: The operation was canceled` — GitHub Actions cancelled the job
+- `Xvfb failed to start` — display server for headless Linux tests failed
+
+**Test flakes** (not infrastructure, but not your fault either):
+- Timeouts on tests that normally pass — slow CI machine
+- Race conditions in async tests
+- Shell integration not reporting exit codes (see terminal.log for `exitCode: undefined`)
+
+**What to do with infrastructure failures**:
+1. **Don't change code** — the failure isn't caused by your PR
+2. **Re-run the failed jobs** via the GitHub UI or:
+   ```bash
+   gh run rerun <RUN_ID> --failed
+   ```
+3. If failures persist across re-runs, check if main is also broken:
+   ```bash
+   gh run list --branch main --limit 10 --json databaseId,conclusion,displayTitle
+   ```
+4. If main is broken too, wait for it to be fixed — your PR is not the cause
+
+---
+
+## Step 7: Fix and Iterate
+
+1. Make the fix locally
+2. Verify compilation: check the `VS Code - Build` task or run `npm run compile-check-ts-native`
+3. Run relevant unit tests locally: `./scripts/test.sh --grep "<pattern>"`
+4. Commit and push:
+   ```bash
+   git add -A
+   git commit -m "fix: <description>"
+   git push
+   ```
+5. Watch CI again:
+   ```bash
+   gh pr checks --watch --fail-fast
+   ```
+
+---
+
+## Quick Reference
+
+| Task | Command |
+|------|---------|
+| Find PR for branch | `gh pr view --json number,url` |
+| List all checks | `gh pr checks --json name,state,bucket` |
+| List failed checks only | `gh pr checks --json name,state,link,bucket --jq '.[] \| select(.bucket == "fail")'` |
+| Watch checks until done | `gh pr checks --watch --fail-fast` |
+| Failed jobs in a run | `gh run view <RUN_ID> --json jobs --jq '.jobs[] \| select(.conclusion == "failure") \| {name, id: .databaseId}'` |
+| View failed step logs | `gh run view <RUN_ID> --job <JOB_ID> --log-failed` (requires full run to complete) |
+| Download job log via API | `gh api repos/microsoft/vscode/actions/jobs/<JOB_ID>/logs > "$TMPDIR/ci-job-log.txt"` (works while run is in progress) |
+| Find error line in log | `grep -n '##\[error\]' "$TMPDIR/ci-job-log.txt"` |
+| Download log artifacts | `gh run download <RUN_ID> -n "<artifact-name>" -D /tmp/ci-logs` |
+| Re-run failed jobs | `gh run rerun <RUN_ID> --failed` |
+| Recent main runs | `gh run list --branch main --workflow <workflow>.yml --limit 5` |

.github/skills/unit-tests/SKILL.md

@@ -0,0 +1,87 @@
+---
+name: unit-tests
+description: Use when running unit tests in the VS Code repo. Covers the runTests tool, scripts/test.sh (macOS/Linux) and scripts/test.bat (Windows), and their supported arguments for filtering, globbing, and debugging tests.
+---
+
+# Running Unit Tests
+
+## Preferred: Use the `runTests` tool
+
+If the `runTests` tool is available, **prefer it** over running shell commands. It provides structured output with detailed pass/fail information and supports filtering by file and test name.
+
+- Pass absolute paths to test files via the `files` parameter.
+- Pass test names via the `testNames` parameter to filter which tests run.
+- Set `mode="coverage"` to collect coverage.
+
+Example (conceptual): run tests in `src/vs/editor/test/common/model.test.ts` with test name filter `"should split lines"`.
+
+## Fallback: Shell scripts
+
+When the `runTests` tool is not available (e.g. in CLI environments), use the platform-appropriate script from the repo root:
+
+- **macOS / Linux:** `./scripts/test.sh [options]`
+- **Windows:** `.\scripts\test.bat [options]`
+
+These scripts download Electron if needed and launch the Mocha test runner.
+
+### Commonly used options
+
+#### `--run <file>` - Run tests from a specific file
+
+Accepts a **source file path** (starting with `src/`). The runner strips the `src/` prefix and the `.ts`/`.js` extension automatically to resolve the compiled module.
+
+```bash
+./scripts/test.sh --run src/vs/editor/test/common/model.test.ts
+```
+
+Multiple files can be specified by repeating `--run`:
+
+```bash
+./scripts/test.sh --run src/vs/editor/test/common/model.test.ts --run src/vs/editor/test/common/range.test.ts
+```
+
+#### `--grep <pattern>` (aliases: `-g`, `-f`) - Filter tests by name
+
+Runs only tests whose full title matches the pattern (passed to Mocha's `--grep`).
+
+```bash
+./scripts/test.sh --grep "should split lines"
+```
+
+Combine with `--run` to filter tests within a specific file:
+
+```bash
+./scripts/test.sh --run src/vs/editor/test/common/model.test.ts --grep "should split lines"
+```
+
+#### `--runGlob <pattern>` (aliases: `--glob`, `--runGrep`) - Run tests matching a glob
+
+Runs all test files matching a glob pattern against the compiled output directory. Useful for running all tests under a feature area.
+
+```bash
+./scripts/test.sh --runGlob "**/editor/test/**/*.test.js"
+```
+
+Note: the glob runs against compiled `.js` files in the output directory, not source `.ts` files.
+
+#### `--coverage` - Generate a coverage report
+
+```bash
+./scripts/test.sh --run src/vs/editor/test/common/model.test.ts --coverage
+```
+
+#### `--timeout <ms>` - Set test timeout
+
+Override the default Mocha timeout for long-running tests.
+
+```bash
+./scripts/test.sh --run src/vs/editor/test/common/model.test.ts --timeout 10000
+```
+
+### Integration tests
+
+Integration tests (files ending in `.integrationTest.ts` or located in `extensions/`) are **not run** by `scripts/test.sh`. Use `scripts/test-integration.sh` (or `scripts/test-integration.bat`) instead.
+
+### Compilation requirement
+
+Tests run against compiled JavaScript output. Ensure the `VS Code - Build` watch task is running or that compilation has completed before running tests. Test failures caused by stale output are a common pitfall.

.github/workflows/no-package-lock-changes.yml

@@ -1,51 +0,0 @@
-name: Prevent package-lock.json changes in PRs
-
-on: pull_request
-permissions: {}
-
-jobs:
-  main:
-    name: Prevent package-lock.json changes in PRs
-    runs-on: ubuntu-latest
-    steps:
-      - name: Get file changes
-        uses: trilom/file-changes-action@ce38c8ce2459ca3c303415eec8cb0409857b4272
-        id: file_changes
-      - name: Check if lockfiles were modified
-        id: lockfile_check
-        run: |
-          if cat $HOME/files.json | jq -e 'any(test("package-lock\\.json$|Cargo\\.lock$"))' > /dev/null; then
-            echo "lockfiles_modified=true" >> $GITHUB_OUTPUT
-            echo "Lockfiles were modified in this PR"
-          else
-            echo "lockfiles_modified=false" >> $GITHUB_OUTPUT
-            echo "No lockfiles were modified in this PR"
-          fi
-      - name: Prevent Copilot from modifying lockfiles
-        if: ${{ steps.lockfile_check.outputs.lockfiles_modified == 'true' && github.event.pull_request.user.login == 'Copilot' }}
-        run: |
-          echo "Copilot is not allowed to modify package-lock.json or Cargo.lock files."
-          echo "If you need to update dependencies, please do so manually or through authorized means."
-          exit 1
-      - uses: octokit/request-action@dad4362715b7fb2ddedf9772c8670824af564f0d # v2.4.0
-        id: get_permissions
-        if: ${{ steps.lockfile_check.outputs.lockfiles_modified == 'true' && github.event.pull_request.user.login != 'Copilot' }}
-        with:
-          route: GET /repos/microsoft/vscode/collaborators/{username}/permission
-          username: ${{ github.event.pull_request.user.login }}
-        env:
-          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
-      - name: Set control output variable
-        id: control
-        if: ${{ steps.lockfile_check.outputs.lockfiles_modified == 'true' && github.event.pull_request.user.login != 'Copilot' }}
-        run: |
-          echo "user: ${{ github.event.pull_request.user.login }}"
-          echo "role: ${{ fromJson(steps.get_permissions.outputs.data).permission }}"
-          echo "is dependabot: ${{ github.event.pull_request.user.login == 'dependabot[bot]' }}"
-          echo "should_run: ${{ !contains(fromJson('["admin", "maintain", "write"]'), fromJson(steps.get_permissions.outputs.data).permission) }}"
-          echo "should_run=${{ !contains(fromJson('["admin", "maintain", "write"]'), fromJson(steps.get_permissions.outputs.data).permission) && github.event.pull_request.user.login != 'dependabot[bot]' }}" >> $GITHUB_OUTPUT
-      - name: Check for lockfile changes
-        if: ${{ steps.lockfile_check.outputs.lockfiles_modified == 'true' && steps.control.outputs.should_run == 'true' }}
-        run: |
-          echo "Changes to package-lock.json/Cargo.lock files aren't allowed in PRs."
-          exit 1

.github/workflows/pr-linux-test.yml

@@ -44,7 +44,9 @@ jobs:
             libxkbfile-dev \
             libkrb5-dev \
             libgbm1 \
-            rpm
+            rpm \
+            bubblewrap \
+            socat
           sudo cp build/azure-pipelines/linux/xvfb.init /etc/init.d/xvfb
           sudo chmod +x /etc/init.d/xvfb
           sudo update-rc.d xvfb defaults

.github/workflows/sessions-e2e.yml

@@ -1,14 +1,13 @@
 name: Sessions E2E Tests
 
-# Disabled: Flaky
-# on:
-#   pull_request:
-#     branches:
-#       - main
-#       - 'release/*'
-#     paths:
-#       - 'src/vs/sessions/**'
-#       - 'scripts/code-sessions-web.*'
+on:
+  pull_request:
+    branches:
+      - main
+      - 'release/*'
+    paths:
+      - 'src/vs/sessions/**'
+      - 'scripts/code-sessions-web.*'
 
 permissions:
   contents: read