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)
AgentSession#setModelWithProviderSessionReset is the single choke point
every model mutation runs through (explicit /model, prewalk hand-offs,
retry-fallback, model cycling). It previously changed agent.state.model
silently — no session event told subscribers (ACP, RPC, TUI) that the
active model moved.
Emit a new model_changed AgentSessionEvent from that choke point
whenever the model actually changes, and wire it into every consumer
that must exhaustively handle AgentSessionEvent: the TUI event
controller (invalidates the status line, same as thinking_level_changed)
and the RPC client's forwarded-event allowlist.
(cherry picked from commit f76325de2c7821dd7046ddb67546577c3575a263)
Anthropic's provider-scoped fastModeDisabled state was omitted from the session active predicate, and the unchanged-tier guard prevented explicit retries.
GitHub Copilot's call_id|id transport (and any stream that delivers a tool's name/args before its id) makes a streamed tool-call block appear with an empty or partial id, then rewrites it in a later delta. The transcript keyed the live card by that mutable content.id, so the changed id passed the creation guard and spawned a second card: the old-id card orphaned as a blue pending preview while the new-id card took the result.
Track the streamed id per tool-call block position (reset per assistant message) and migrate the live card's id-keyed trackers (pendingTools, tool timeline, args reveal, read tracking, and the shared read group's entry) when the id changes, so the populated id reuses the existing card.
Fixes#6879
Attaching to a long-running browser (a signed-in profile, an Electron app kept
open for a session) meant repeating app.cdp_url on every browser call, and any
call that omitted it silently launched a fresh headless Chromium instead.
browser.cdpUrl supplies that endpoint once. It is a default rather than an
override: app.cdp_url and app.path still win, and an unset or blank value leaves
cmux and headless resolution exactly as before.
Attaching over app.cdp_url points automation at a browser the user is driving,
so two behaviors that are correct for a browser we own are wrong there.
pickElectronTarget enumerated CDP targets and took the first usable one, which
is not necessarily the tab in front of the user, and #captureScreenshot always
called page.bringToFront(), which switches the user's visible tab and pulls
window focus on every screenshot.
Connected browsers now prefer a tab that reports document.visibilityState
"visible" and skip the pre-capture activation, accepting the compositor stall
risk that activation avoids. Headless and spawned browsers are unchanged.
buildInitPayload dropped opts.url, opts.waitUntil and opts.timeoutMs on the
attach branch, so `browser open` with a url against app.cdp_url or app.path
adopted the existing target without navigating and reported its current url as
the result. Reusing the same tab name afterwards did navigate, because the reuse
path issues tab.goto, so the same call behaved differently on first open.
Thread the navigation fields through the attach arm of WorkerInitPayload and
goto after the page is adopted and the dialog policy is installed, mirroring the
headless arm.
The !restrictToolNames guard on the pairing blocks was wrong: a restricted
session with tools:[checkpoint] passes isToolAllowed (requestedTools is
defined) but the pairing is skipped, stranding the agent without rewind.
Remove the guard — this is a safety pairing, not a convenience widening.
Added restricted-session tests in both createTools and SDK active-set paths.
Address Codex review: createTools auto-includes the sister tool in the
registry, but createAgentSession rebuilds the active set from the original
toolNames — so a one-sided tools: entry left the sister tool registered
but inactive. Mirror the pairing into explicitlyRequestedToolNames, gated
to !restrictToolNames for consistency with the manage_skill/learn mirror.
Also gate the index.ts pairing block with !restrictToolNames to match its
AST/auto-learn siblings, and fix the prompt to say 'or' not 'and'.
Address review feedback on PR #6938:
- One-sided tools: list checkpoint without rewind (or vice versa) now
auto-includes the sister tool, preventing a stuck subagent
- Add changelog entry under [Unreleased]
Closes#3762
When an agent definition's frontmatter list explicitly includes
checkpoint, rewind, learn, or manage_skill, allow them in subagents.
Previously all four were hard-gated to top-level sessions.
- Relax taskDepth gates in isToolAllowed using the already-captured
requestedTools variable (no signature change needed)
- Remove isTopLevelSession function and its 4 guard sites from checkpoint.ts
- Update checkpoint prompt with enablement docs
- Add tests for subagent explicit-request, no-request, disabled-setting,
and top-level paths
Legacy pi extensions import both from the `@earendil-works/pi-coding-agent`
package root, which omp aliases to legacy-pi-coding-agent-shim.ts. `parseArgs`
lives in ../cli/args and CONFIG_DIR_NAME in @oh-my-pi/pi-utils, and neither is
reachable through `export * from "../index"`, so Bun's static export check
rejects such extensions during validation.
Same class of barrel gap as issues #5968 and #6583.
`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.
When a successful read result was persisted before its live tool_execution_end reached the UI, a transcript rebuild replayed the completed card and removed the pending handle. The delayed read completion then created a fallback ReadToolGroupComponent beside replay.
Treat the existing tool timeline entry as proof that the read already had a card; clear stale read tracking and skip fallback creation. Added an exact memory:// success -> persisted replay -> delayed completion regression.
Fixes#6879
The guard now probes the full target before refusing, so an existing file
named like a selector list stays writable. Say so in the CHANGELOG entry
and the readSelectorListMisfire doc comment.
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.
