The previous reset dropped #pendingXdevMountDelta alongside the announced
baseline. Unlike /new and different-session switchSession, branch() does
not rebuild the base system prompt afterward, and because the device is
already in mountedNames no later refresh re-queues an add delta. Dropping
the undelivered delta therefore left the branched transcript unaware of a
still-mounted discoverable device.
Only the announced baseline is reset now; pending adds (still-live mounts
awaiting delivery) survive and announce on the next prompt in the new
transcript. Redundant on /new (the rebuilt prompt lists them too) but
harmless, and correct for branch.
Fixes#6921
(cherry picked from commit 5866440f27c15a320657e25fbfa0d2d65aad1fa2)
The announced-mount baseline persisted across /new, switchSession, and
branch, which replace agent.state.messages but only clear session-scoped
tool state. A device announced in the old transcript stayed in the cache,
so reconnecting it into the fresh history was filtered as already known
and never announced, leaving the new conversation unaware of the device.
Reset the announced baseline (and any undelivered pending delta) from
#clearSessionScopedToolState, so the next notice re-seeds from the new
transcript and a reconnecting device announces again.
Fixes#6921
(cherry picked from commit d06dde02b9de4aacacd7aea5ee51edc7e524e3fb)
Replayed the stable added and removed inventory sections from legacy
xdev-mount-notice content when structured details are absent. This keeps
the first post-upgrade resume from re-announcing devices that persisted
history already introduced.
Covered both structured and legacy resume histories, including removed
devices and inline docs that must not be interpreted as inventory.
Fixes#6921
(cherry picked from commit 634a4c2de75f99e219f408c56bed83c04fe1290a)
Mount-notice injection diff-gated only against the in-memory mountedNames
set, which is reseeded on every process resume / host reconnect. Dynamic
devices (MCP / RPC host) already announced in persisted history therefore
re-announced, splicing a redundant developer message that busts the
provider prompt-cache prefix and re-bills the whole suffix at full price
on metered providers.
Notices now persist a structured { added, removed } payload. On the first
consumption after resume the announced-device baseline is reconstructed
from history, and only a net change relative to what the model already
knows is announced, so a resume re-establishing the same inventory emits
nothing.
Fixes#6921
(cherry picked from commit 03c2ed5189510f41431bd164fa80187a69ed8de9)
formatAvailableResources only listed concrete resources, so the
assistant-facing summary shown on a failed mcp:// read understated the
server's contract even though template routing and /mcp resources
already handle them. Now templates are listed alongside concrete
resources.
Fixes#6911
(cherry picked from commit 254f35bb04cda8a615bbe1291d73b13cac0eabaa)
Zed (and any other ACP client) never learned about a model switch that
happened from inside the agent loop — prewalk hand-offs, retry-fallback,
model cycling — because #pushConfigOptionUpdate was only ever wired to
the client-initiated setSessionConfigOption/setSessionMode RPCs and to
the thinking_level_changed lifetime event. The model itself did switch
correctly (subsequent requests used the new model), but the client's
model picker/status bar kept showing the session's starting model.
#handleLifetimeEvent now also reacts to the model_changed event added
in the previous commit and re-pushes config_option_update. Extend the
existing thinking-only subscription dedupe in setSessionConfigOption to
cover the model config id too, so a client-initiated model change still
produces exactly one notification once the lifetime subscription is
installed.
Regression tests mirror the existing thinking-level coverage:
- 'pushes config_option_update when the model changes internally'
- 'emits a single config_option_update per setSessionConfigOption(model) call'
Verified: bun test test/acp-agent.test.ts (57/57), plus
agent-session-prewalk.test.ts, agent-session-retry-fallback.test.ts,
retry-fallback.test.ts, model-resolver.test.ts, and the other acp-*.test.ts
files all still pass; tsgo --noEmit and biome check clean.
(cherry picked from commit f5c5081088e8cbac2650a9de89049731de1b2777)
`omp ttsr test <file>` inferred the match source from the path extension
against a hardcoded allowlist (`SOURCE_FILE_EXT`); a supplied source file
whose extension was absent silently fell through to the text (prose)
context, where tool-scoped rules can never match. The result was a false
negative indistinguishable from a non-matching regex, contradicting the
documented "a positional that resolves to a file defaults to tool/edit
context" contract.
- Emit an explanatory note when a resolvable file path is supplied and the
source is inferred as `text`, pointing at `--source tool --tool edit`.
Surfaced in both text and `--json` output via `TestReport.inferenceNote`.
- Extend the allowlist with the .NET family and other common source
languages (cs, razor, cshtml, fs, fsx, vb, sh, bash, sql, zig, dart,
scala, ex, exs, proto, tf).
Left the fall-through default itself unchanged (inverting the test is a
behaviour change and a maintainer call).
Fixes#6887
- Update isActionableDisable in usage-cli.ts to accept active accounts and check identity matches.
- Suppress credential disable tombstones when an active account exists for the same provider and identity.
- Add test coverage for suppressing tombstones when active accounts share the same identity.
Both PR heads carried discrete drive-by commits bumping only a test
timeout, unrelated to the Markdown-layout and HTML-asset fixes they
ship. Restored to the pre-merge state to keep the merged scope honest.
Probe the full target with probeLiteralPathExists before classifying it as a
mis-dispatched read-selector list, matching the single-selector guard, so an
existing POSIX file like 'report:1-2;archive:3-4' can still be overwritten.
can1357