* Collect and package Agent Host debug logs on the host
"Export Agent Host Debug Logs" previously had the client guess the paths of
host-owned log files and open them one by one. The Agent Host now discovers
and packages its own diagnostics, including the Copilot SDK runtime logs
obtained via the SDK's own collectLogs API rather than by searching the disk.
Ownership is split: the host packages host-owned logs into an artifact, while
the client keeps contributing the logs it owns (renderer, shared process, AHP
transport JSONL, usage and customization sidecars). Native exports flatten the
host archive into the single resulting zip; browser builds keep folder export.
This is exposed as a private, non-spec AHP extension command
(vscode/collectAgentHostDebugLogs) so the shape can settle before it is
proposed for the protocol. Hosts that predate it answer MethodNotFound and the
client falls back to the previous discovery path.
Remote hosts return an artifact URI whose bytes are streamed back through a
second private command (vscode/readAgentHostDebugLogsChunk) in bounded 1 MiB
chunks, so a whole archive never has to be Base64-encoded into one JSON-RPC
message. Only artifacts the collector itself produced are readable, so this is
not a general-purpose file read. A local Agent Host returns a plain file URI
and its bytes never cross IPC at all.
Artifacts are size-capped, expire on a lease, and are cleaned up on shutdown.
Host-side collection failures are non-fatal: the export falls back to
client-side collection so it still produces the logs the client owns.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* Don't let host-side log collection hang the debug-logs export
Manual end-to-end testing of "Export Agent Host Debug Logs" found the command
could appear to do nothing at all: no save dialog, no error, no log output.
Host-side collection goes through the agent host management channel, which
waits for the host to reach a connected state. When the host never gets there
-- easy to hit by running the command during startup, or when the protocol
channel handshake times out -- that request stays pending forever, and since
the export awaited it directly, the whole command hung silently.
Bound the collection and fall back to client-side discovery when it does not
finish in time, so an export always produces the logs the client owns. The
previous change already treated collection *failures* as non-fatal; this
extends the same guarantee to a host that never answers.
A late-arriving artifact is discarded rather than leaked, since nothing is
waiting for it by the time it lands.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* Give host-side log collection a longer bound
Raise the host-collection timeout from 20s to 30s. Manual testing showed a
real collection has to zip the host's logs, which can be large, so the
original bound was tight enough to risk dropping host logs from a host that
was merely slow rather than stuck.
Also correct the comment: the failure this guards against is a host that
never answers at all, not merely one that is unreachable.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* Fix local agent host management calls hanging forever
Every call through the local agent host management channel -- Network
Diagnostics, and the new debug-log collection -- could hang forever with no
error and no output.
`_getManagementService()` was an `async` method that returned the management
service. That service is a `ProxyChannel` proxy whose `get` trap answers
*every* string property with a function, including `then`. Resolving a promise
with such an object makes the runtime treat it as a thenable and invoke `then`
as if it were a remote method, so the promise never settles and the caller
waits forever. It also puts a bogus `agentHostManagement.then` request on the
wire, whose malformed reply is the source of the "Unexpected end of JSON input"
deserialization errors seen in the agent host log.
Split the wait from the lookup: `_whenManagementConnected()` resolves `void`,
and the proxy is obtained synchronously afterwards, so it is never passed
through a promise.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* Collect debug logs on the Agent Host only, with no client-side fallback
The export had two implementations of host-log discovery: the Agent Host's
own collector, and a client-side path-guessing fallback used whenever the
host artifact was missing or incomplete, guarded by a 30s timeout. That is
a lot of machinery to keep a second, less accurate implementation alive.
Make the host path the only path. The client now contributes only the logs
it genuinely owns (window/shared-process output channels, AHP transport
JSONL, and the client-local capture sidecars); everything host-owned comes
from the artifact. If collection fails, the failure surfaces to the user
instead of being silently replaced by a lesser result.
The host can now produce those logs in the case that previously forced the
fallback. `collectDebugLogs` no longer requires a live session: with no
session to reach the SDK through, the provider copies the most recent
Copilot process log straight off the host's own disk, where it knows the
real location rather than guessing it from the client.
Because those logs can reach hundreds of megabytes, the collector now keeps
only the trailing bytes of any file over a per-file cap. That bounds the
artifact whether the file came from the SDK bundle or was copied in
directly, and the tail is the part that explains a recent failure. In
practice this takes a local export from ~44 MB to ~2.5 MB.
Also drops the remaining whole-file Base64 copy that a remote export could
silently fall back to when streaming was unavailable; streaming is now
required.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* Require a live session for Agent Host debug-log collection
Remove the remaining no-session implementation and make the live session URI
required through the client, private extension protocol, management bridge,
AgentService, collector, and provider contracts.
The workbench command now reports an error when there is no active Agent Host
chat. The Agents Window no longer substitutes its most recently updated,
possibly closed session. On the host, the session must resolve to its owning
provider, and Copilot must resolve it to a live SDK session before invoking
`session.rpc.debug.collectLogs` with events, process logs, and shell logs.
Providers without additional diagnostics still contribute the Agent Host
process log through the same collector. If a provider implements collection,
its failure propagates and fails the export rather than silently returning a
partial archive.
This leaves one success path and no client-side or direct-disk fallback.
(Written by Copilot)
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* Allow Agent Host debug-log export without an active session
A host-wide export is valid without an active chat. Keep the session optional
through the client, private protocol, management bridge, AgentService,
collector, and provider contracts.
With a live session, Copilot asks that exact SDK session for events, process
logs, and shell logs. Without a live session (including a New Session
placeholder whose SDK session has not started yet), it uses any live Copilot
SDK session only as the gateway for process logs, explicitly excluding that
unrelated session's events and shell logs. If no SDK session is live, the same
host collector still packages the Agent Host process log.
The client still adds the logs it owns: window/shared output, all applicable
AHP JSONL logs, remote-forwarded output channels, and capture sidecars. No
direct process-log path scan or client-side host-log fallback is reintroduced.
(Written by Copilot)
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* Require debug-log collection on Agent Host connections
Every real Agent Host connection implements debug-log collection and bounded
artifact reads. Make both methods required on `IAgentConnection`, implement
them as explicit unsupported operations on the browser null service, and
remove workbench guards that could never detect an older remote server.
Provider-specific diagnostics remain optional: that controls what the host
adds to its artifact, not whether the connection supports the collection API.
(Written by Copilot)
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* Harden Agent Host debug-log artifacts and remote export
Enforce the same 1,000-file limit while staging that the native ZIP merger
uses, and include an exact normalized file manifest in each artifact. Remote
clients validate the manifest's paths, entry sizes, uniqueness, aggregate
size, and entry count.
Use that manifest to stream browser remote-directory files through bounded
1 MiB artifact reads instead of whole-file Base64 resource reads. Retained
directory artifacts whitelist only the regular files that were enumerated,
so the chunk endpoint remains artifact-scoped. Local browser copies verify
the manifest against file type, symlink state, and size before copying.
Restore the active remote Agent Host forwarded output channel, and preserve
text MIME types in resourceRead while retaining binary Base64 support.
Align archive validation with the collection contract: at most 16 MiB on the
wire, while highly-compressible archives may expand to the bounded 256 MiB
staging limit.
(Written by Copilot)
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* Stabilize debug-log artifact cleanup tests
Replace fixed 20 ms sleeps with bounded polling for the actual temporary
directory state. Artifact expiration triggers asynchronous filesystem removal,
so a busy CI machine can observe the timer firing before `rm` has completed.
(Written by Copilot)
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
---------
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Document how to reproduce a UI scenario through the automation MCP and capture video, screenshots, a trace, and an HTML report, and let evidence capture skip the in-window step banner so the recording shows unmodified product UI.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: adb443eb-11e5-40a1-8608-7f593fa79485
* list: preserve selection during shift-click
Keep retained virtualized rows when the user extends an existing text selection.
- Do not release the active selection range before Shift+Click updates the DOM selection.
- Add a regression test for extending a selection after its anchor scrolls offscreen.
Fixes https://github.com/microsoft/vscode/issues/302390
(Commit message generated by Copilot)
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* list: retain shift-drag movement tracking
Keep selection retention separate from per-gesture movement tracking.
- Re-arm selection drag listeners when Shift extends an active selection.
- Dispose selection and movement stores through the list lifecycle.
- Exercise Shift+drag events and active-selection disposal in the regression test.
(Commit message generated by Copilot)
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
---------
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
fix: use fresh service accessor when lazily initializing chat attachment context
Fixes#329610, #331400
hookUpSymbolAttachmentDragAndContextMenu captured a ServicesAccessor
and reused it inside the lazily-invoked ensureContextKeyService
closure, which runs on context-menu open, long after the accessor's
originating invokeFunction call had returned. Reading services from
the expired accessor threw "Illegal state: service accessor is only
valid during the invocation of its target method".
Fix at the producer: get a fresh accessor via
instantiationService.invokeFunction(...) for the deferred
setResourceContext call, matching the pattern already used by the
dragstart handler a few lines above.
Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
* Fix Agent Host startup with invalid telemetry level
Fail closed when the telemetry level is malformed, prevent invalid Agent Host process arguments, and surface terminal startup failures without reconnecting.
(Written by Copilot)
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* Test fatal Agent Host notification wiring
Exercise the service listener before and after the initial connection so notification wiring and suppression remain covered.
(Written by Copilot)
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
---------
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* agentHost: validate managed permission rules before sending
The SDK rejects the entire managed permissions document when a single rule
fails to parse, and VS Code sends that document as part of session create and
resume, so an untranslatable rule derived from a user's settings fails the
session outright.
Add a rule builder that mirrors the runtime's grammar and returns undefined
for anything the SDK would reject, so callers drop the individual restriction
instead of poisoning the document. Notably the builder refuses glob negation,
which is legal in VS Code settings but has no equivalent in the runtime's glob
engine, and refuses a bare wildcard domain, which parses but matches nothing —
the kind-only rule is the correct way to express an entire family.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* agentHost: deduplicate merged managed permission rules
Two settings can legitimately restrict the same operation, and the resolver
concatenated their contributions, so the same rule could be sent twice and be
parsed and evaluated separately by the runtime.
Merge through sets instead, and document why this bridge never contributes an
allow list: a covered request resolves to managed_allow, which the runtime
treats as approval and returns without prompting, and a lone allow list is not
intersected against other managed sources — so contributing one could relax an
MDM policy rather than reinforce it.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* agentHost: declare which config layers drive each managed mapping
The two existing mappings disagreed on source fidelity, and the reason lived
only in the shape of each transform: global auto-approve tested the source
inline while terminal auto-approve accepted any global layer.
Make it a property of the mapping instead. Restrictions that take a capability
away for good default to policy-only, so a personal preference is never
promoted into a restriction the user cannot lift; mappings whose VS Code
behavior already honors user and application values opt into anyGlobal.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* agentHost: bridge denied agent network domains to managed rules
An enterprise that restricts agent network access through chat.agent.networkFilter
had no equivalent restriction in local Agent Host sessions.
Map the blocking half of that filter onto managed Domain deny rules, including
VS Code's restrictive default where turning the filter on without configuring
either list blocks everything. The allow list is deliberately not mapped: VS Code
blocks whatever a populated allow list omits, but a managed allow entry does not
block what it omits — unmatched requests fall through to a prompt the user can
approve — so bridging it would downgrade a block into a prompt.
A bare '*' denial becomes the kind-only Domain rule, since the SDK normalizes
rule arguments as URL patterns and would not read '*' as every host.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* agentHost: bridge terminal auto-approve denials to managed rules
Commands an enterprise had marked as requiring explicit approval in
chat.tools.terminal.autoApprove were auto-approvable again once the session
moved to the local Agent Host.
Map those entries onto managed shell ask rules. Ask rather than deny: the
setting means "require explicit approval", which the host-side auto-approver
already implements by prompting, whereas managed deny is terminal and would
take the user's approval path away entirely.
Regular-expression keys and entries that match the whole command line have no
equivalent in the SDK's shell rule grammar, so they are skipped rather than
approximated by a broader rule.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* agentHost: document the managed settings bridge scope
The bridge's boundaries were discoverable only by reading each mapping: that it
contributes restrictions and never widens access, that it reads global layers
only so one workspace cannot affect another window's sessions, that a setting is
skipped rather than approximated when it does not survive translation, and that
it reaches Copilot sessions on a local host but not remote hosts or other agents.
Write them down, and say the same in the setting description so an administrator
enabling the bridge can see what it does and does not cover.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* agentHost: honor long-form terminal auto-approve denials
An entry written as { approve: false } means the same thing as a bare false
unless it also opts into whole-command-line matching, but only the bare form was
being bridged, so an enterprise using the long form got no restriction in the
session.
Match both, and keep skipping the matchCommandLine variant, which changes what
the rule matches and has no equivalent in the SDK shell grammar.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* agentHost: match legacy semantics when translating denials
Three translations did not match what the legacy settings actually mean, so
restrictions an administrator configured were either lost or widened:
- Denied domains were passed through verbatim, but the network filter matches on
the hostname alone. A denial written as a URL or with a port blocked the whole
host in VS Code while emitting a narrower rule here, leaving the rest of that
host reachable. Reduce each entry the same way the filter does.
- The regular-expression test accepted any key with a second slash, so an
absolute command path such as /usr/bin/rm was skipped even though the
auto-approver treats it as a literal. Mirror the auto-approver's own test,
which requires the trailing slash to be followed only by flags.
- A key containing * is a literal in VS Code but a command-boundary wildcard in
the SDK, so 'git *' would have required approval for every git command. Skip
those keys rather than broaden the denial.
Also replace the deduplication test, which combined two distinct rules and so
passed whether or not deduplication happened, and trim documentation that had
been duplicated between the module comment and individual declarations.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
---------
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* Force the Agent Host harness when the sandbox is managed
Enterprises in the sandbox pilot enforce `chat.agent.sandbox.enabled` (or
`chat.agent.sandbox.enabledWindows`) through managed settings. Treat that as the
governance signal for the chat harness: hide the legacy local harness from the
new-chat pickers and default new chats to the Agent Host Copilot SDK, without the
administrator having to also push `chat.editor.localAgent.enabled`,
`chat.defaultToCopilotHarness` and `chat.editor.preferCopilotHarness`.
A user- or workspace-level sandbox opt-in does not trigger this, and existing
local chat sessions keep running on the local harness. The decision is reported
in the Policy Diagnostics developer report.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* Report the effective harness decision, not just the signal
Address PR review feedback:
- `chat.editor.localAgent.enabled` and `chat.defaultToCopilotHarness` descriptions
claimed the policy always applies, but virtual workspaces are checked first and
keep the local harness. Scope both descriptions to non-virtual workspaces.
- Policy Diagnostics reported the harness as unconditionally hidden/forced whenever
the policy signal was active. Split the section into the governance signal and the
effective decision in this window, deriving the latter from the workspace kind and
Agent Host enablement, which `getComputedDefaultSessionType` also depends on.
Also export the harness setting ids from the platform module so the diagnostics
labels stay in sync with the registration, and cover the case where a governed
window has no Agent Host and no contributed harness.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* Key enforcement on the only policy-backed sandbox setting
A review council independently found that the `chat.agent.sandbox.enabledWindows`
branch could never fire. `inspect().policyValue` is only populated for settings
that declare a policy (`PolicyConfiguration.update`), and unlike
`chat.agent.sandbox.enabled` that setting declares none, so its policy value is
permanently undefined. The accompanying test fabricated a policy value the real
configuration service cannot produce for that key, so it asserted behavior on a
state unreachable in production.
Key the governance signal on `chat.agent.sandbox.enabled` alone and drop the dead
field, its picker listener, and the fabricated test case. Add a test locking in
the real contract: the Windows setting must not act as a signal, so a local user
opt-in on Windows cannot silently retire the local harness.
Sandboxing is per-platform while enforcement is fleet-wide, so Policy Diagnostics
now reports the platform-appropriate sandbox setting and whether the sandbox is
actually active on this machine, instead of implying an enforced user is sandboxed.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* Key harness enforcement on the SDK sandbox managed setting
The previous revision keyed on `chat.agent.sandbox.enabled` — the VS Code
terminal-engine sandbox that the *local* harness uses — which is the wrong
signal. The sandbox the pilot enforces is the Copilot SDK sandbox floor,
delivered as the runtime-owned `sandbox.enabled` managed setting
(`force-on-wins` in the runtime's managed-settings schema) and applied by the
Agent Host over AHP.
Read that key directly from the managed-settings channels instead of through a
VS Code configuration policy: the control is runtime-owned, so mirroring it as a
`policy:` declaration would invert ownership. `sandbox.enabled` is registered as
a pipeline-consumed control (like `forceRemoteSettingsRefresh`) so native MDM
watches it without any setting declaring it, and resolution follows the standard
native MDM > server > file precedence.
The enablement service exposes the result as a `managedSandboxEnforced`
observable, which the harness decision points take as an explicit argument
rather than re-reading configuration.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* Apply the sandbox floor on every new-chat path and trim the diff
A review council unanimously found that the floor never reached the real New
Chat entry points. `managedSandboxEnforced` was an optional parameter defaulting
to `false`, so every call site that was not updated silently opted out: the
picker hid the local harness while the New Chat, panel and editor actions kept
creating local sessions the user could no longer re-select, and a remembered
local selection kept overriding the mandated default.
Thread the flag through `getDefaultNewChatSessionResource` and remembered-type
resolution, and supply it from every production call site. Cover both the
resource path and the remembered-local override with a regression test.
Also drop the file managed-settings channel: it was accepted as an optional
constructor argument that no concrete service ever supplied, so its precedence
branch was unreachable while diagnostics still reported the channel. Resolution
is now native MDM plus server, matching `shouldForceRemoteSettingsRefresh`;
wiring the file channel is follow-up work.
Trim the rest to what the change needs: collapse the Policy Diagnostics section
to a single table, unexport two module-private helpers, and revert the exported
setting ids that only existed to label the removed diagnostics rows.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* Resolve sandbox floor with managed-settings precedence
Use the canonical native MDM, server, and file precedence when deciding whether the managed sandbox floor should retire the local harness. Observe file-managed changes and include that channel in policy diagnostics.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* Encapsulate managed settings resolution
Expose effective managed values from AccountPolicyService through a source-agnostic platform service. Agent Host now observes one resolved sandbox value instead of depending on native, server, and file channel implementations.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* Fix Agent Host test service mocks
Register the effective managed-settings service in web enablement tests and complete the Agent Host enablement mock used by chat component fixtures. Format the earlier test-stub updates so hygiene accepts them.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* Restore chat harness setting descriptions
Remove the managed-sandbox qualification from the existing harness setting descriptions and leave their behavior documentation unchanged.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* Keep local harness when Agent Host is unavailable
Apply the managed sandbox harness override only while Agent Host is enabled, including picker visibility and remembered session usability. Also reduce policy diagnostics to the effective harness decision.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
---------
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* Initial plan
* Add mute-mic button and transcript quick toggle for Agents Voice Mode
Co-authored-by: meganrogge <29464607+meganrogge@users.noreply.github.com>
* Add mute-mic control to shared chat inputs across all windows
Render the Voice Mode mute/unmute control in the segmented voice pill so
it appears in every chat input, not just the Agents Voice widget. Extend
the pill's active context key to any connected session (previously only
manual, non-hands-free). While muted, the waveform and input glow fall
back to the calm idle state instead of reacting to the user's voice, and
the listening placeholder reads "Unmute to speak...".
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* Only read voice mute state when connected/listening to fix fixtures
The muted-idle fallback read isMuted unconditionally in the pill and
voice input decoration autoruns, which crashed component fixtures whose
mock IVoiceSessionController does not stub isMuted. Gate the reads on the
connected/listening state (matching how the other voice observables are
read) so idle/disconnected surfaces no longer depend on isMuted.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
---------
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: meganrogge <29464607+meganrogge@users.noreply.github.com>
Co-authored-by: meganrogge <merogge@microsoft.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* Support info message and fix deprecations
* Cleanup exception code
* Announce model picker notices to screen readers
Addresses PR review feedback:
- Fold the hover's warning and info banners into the model row's
ariaDescription, stripped of markdown and prefixed with severity.
- Use model_relocated for the neutral infoText examples, since
model_pending_deprecation maps to a warning.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
---------
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* Use 'No workspace' label for automation quick-chat target
Align the automation definition card and the non-compact quick-chat
row badge with the folder picker's 'No workspace' option, so
workspace-less automations read consistently across the UI.
* Update Sessions list spec for 'No workspace' badge
Match the SESSIONS_LIST doc to the renderer. Regular quick-chat and
history rows now display 'No workspace' instead of 'Chat'.
* test: cover automation card target label rendering
Assert workspace targets render the folder name and non-workspace targets render 'No workspace'.
* signing commit
Prevent an unavailable provider catalog from being accepted as an authoritative partial session list. Retry migration before listing and preserve the failed state so the client cache is not reconciled as session deletion. Fixes#331452.
(cherry picked from commit dcc387ba7e)
Co-authored-by: Sandeep Somavarapu <sasomava@microsoft.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* agentHost: attribute default turns to bound model
Use each provider's concrete chat model to fill turn telemetry before usage arrives, while preserving default/auto/explicit selection semantics and existing privacy normalization.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* agentHost: bind deferred Copilot chats to their creation model
Record the creation model on a reserved chat backing so model attribution covers Copilot's deferred-chat path, where the model previously stayed on the provisional session and left turns unattributed.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
---------
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* Agents - refactor "New Session" and "New Session From" actions into a split button
* Potential fix for pull request finding
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
* Pull request feedback
---------
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
* Reconcile external sessions in a single catalog pass
Changing `chat.agentSessions.showExternal` took 30-50s to take effect on a
profile with ~600 sessions. `_reconcileExternalSessions` walked the whole
session catalog once per mode on a mode change, and each walk opens every
registered session's database. The session list kept showing the old setting
for that whole window, so a later reconciliation looked like sessions randomly
disappearing.
Derive both the outgoing and incoming visible sets from a single
`listSessions(All)` pass. `All` is a superset of every mode and
`_shouldIncludeSession` is a pure predicate over the rows, so this is
equivalent.
Also add logging that was missing to diagnose this:
- each window logs what it mirrors into the shared host root config, and from
which configuration target (these keys are last-writer-wins across windows)
- external-sessions mode transitions
- reconciliation duration and published/retracted/visible counts
- catalog pass timing, promoted to info above 1s
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* Address review feedback
- Redact mirrored configuration values in the log. The sync registry accepts
arbitrary values and anticipates machine-local settings (`localOnly`), and
`chat.tools.autoApprove.edits` already mirrors user-authored glob patterns,
so only closed-set values (booleans, numbers, declared enum members) are
printed verbatim; everything else logs its type.
- Add a regression test asserting a mode change performs a single catalog
pass, covering the `Recent` transition. Verified it fails against the
previous two-pass implementation.
- Correct the `_resolveModeChangeVisibility` JSDoc, which wrongly called
`_shouldIncludeSession` pure, and shorten it.
- Condense the remaining inline comments.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
---------
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Reuse one root-configuration gate and trace format for model publication and session setup. Clarify that setting changes apply after synchronization.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Use synchronized root configuration as the sole source of BYOK enablement and simplify the related logging and tests.\n\nCo-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>