@qwen-code/qwen-code 0.23.1-preview.2 → 0.23.2-preview.0

package/bundled/qc-helper/docs/conversations-recovery.md

@@ -0,0 +1,102 @@
+# Conversations writer locks and recovery
+
+Updated daemons can share Conversations and use different sessions at the same
+time. A loaded session still has one writer. Live activation belongs only to
+the exact publisher of the stable Live locator; losing Live publication does
+not disable standalone conversations.
+
+## A conversation will not open
+
+`session_writer_conflict` means the writer fence prevented access. It can mean
+another process has the conversation open, or that a residual lock cannot be
+safely reclaimed. It is not proof that another writer is currently alive.
+`session_writer_unavailable` means ownership could not be verified; retrying
+does not authorize bypassing it. Archive and delete can return HTTP 200 with a
+writer error for an individual session. Check every result item.
+
+Close the conversation in the owning Qwen process normally, then use **Try
+again** in the affected conversation. You can continue using other sessions.
+Do not create a replacement conversation merely to make the error disappear.
+
+After an ungraceful shutdown, a Linux reboot or a container restart into a new
+PID namespace can leave an unsealed active writer record fenced indefinitely.
+There may be no surviving owner to close. Follow
+[Operator recovery for a residual lock](#operator-recovery-for-a-residual-lock)
+instead of repeatedly retrying; this release does not reclaim across those
+identity boundaries automatically.
+
+If it persists, enable local debug logging (`QWEN_DEBUG_LOG_FILE=1`) when
+starting the affected daemon and inspect the daemon and ACP child's diagnostics.
+Lease-acquisition diagnostics include the session ID, error kind, and exact
+`lockPath` resolved from that writer's runtime storage. Do not guess a lock path
+from the primary workspace or a default home directory. Public HTTP/ACP errors
+intentionally omit paths and ownership records. Keep diagnostic files private;
+do not publish owner tokens or unredacted lock contents.
+
+## Which state can recover automatically?
+
+These rules apply to session writer leases. Legacy global owner records use
+the more limited compatibility check described below.
+
+- Normal close releases the lease. A certified sealed handoff is accepted only
+  when its transcript proof is still valid.
+- A dead active writer is reclaimable only when the existing identity checks
+  establish that its process belongs to the same verified liveness domain.
+- Live or stalled writers remain fenced. Killing a daemon is insufficient if
+  its ACP writer child survives.
+- Foreign or missing boot/process-namespace identity is not proof of death.
+  An absent PID in your namespace does not prove a foreign writer exited.
+- Malformed records, uncertain transcript identity, and residual transition
+  claims fail closed. Elapsed time alone never authorizes takeover.
+
+## Operator recovery for a residual lock
+
+1. Identify the exact affected session and storage from local diagnostics.
+   Preserve the failure log and a private backup of its transcript and lock
+   artifacts. Record which binaries and hosts may access this storage.
+2. Stop or otherwise fence **every possible writer**, including detached ACP
+   children, other daemons, containers, namespaces, and machines sharing the
+   filesystem. Verify the fence from the relevant host/namespace. If you cannot
+   establish this, stop here and ask an operator who can.
+3. Inspect the exact record and any associated claim/retired artifacts with a
+   maintainer. Determine whether the last transcript and handoff proof are
+   authoritative. Do not edit ownership identity fields to manufacture a match.
+4. Only after writers are fenced and evidence is backed up, move individually
+   verified residual artifacts to private recovery storage under operator
+   supervision. Never recursively delete a lock directory or remove all locks.
+5. Start one updated daemon, restore the original session, and verify its last
+   recorded turn before appending. Retain the backups until continuity is
+   confirmed. Bring other updated daemons back only after that check.
+
+There is no force-unlock API or automatic cross-boot/TTL takeover in this
+release. When safe ownership cannot be established, retain the fence.
+
+## Coordinated upgrade and rollback
+
+The backend cutover and Web Shell local-error/retry changes must ship in the
+same release. This is **not a mixed-version rolling upgrade**: older daemons
+can create a global owner after an updated daemon has already started.
+
+Before upgrading, drain all old sessions and scheduled work, stop all old
+daemons and their ACP children, preserve runtime data, and only then start the
+updated binaries. An updated daemon encountering a live legacy owner returns
+`503 conversation_runtime_in_use`; after that owner exits, retry without
+restarting. Only an exactly revalidated stale legacy record is retired.
+Malformed or unsafe legacy state requires operator investigation.
+
+The legacy `conversations/runtime-owner.json` record carries a PID and nonce,
+but no hostname, boot ID, or PID-namespace identity. Its compatibility check
+can only test whether that PID exists in the updated daemon's own host and
+PID namespace. It cannot detect an old writer that is alive elsewhere on shared
+storage. This is another reason to fence every possible writer before starting
+an updated daemon; the check does not make mixed-host or mixed-namespace
+upgrades safe.
+
+Before rollback, drain and fence every updated daemon and writer too. Inventory
+active, sealed, claim, retired, and extended-schema records. Confirm the target
+binary understands each retained schema and handoff state; never feed an
+unsupported schema to an older writer or delete its protective record to make
+rollback proceed. If compatibility cannot be established, keep writers stopped
+and use maintainer-guided recovery or the coherent pre-upgrade backup. Never
+restore an old transcript over later authoritative turns without explicitly
+accounting for those turns.

package/bundled/qc-helper/docs/features/channels/overview.md

@@ -118,7 +118,7 @@ The catalog is private to the exact channel, chat, and sender. Task names use 1
 
 Named results identify their originating task: direct chats use `[task]`, while group chats use `[sender · task]`. Named text permission prompts also show the exact request ID and the corresponding `/approve <id>`, `/approve-always <id>`, and `/deny <id>` commands. The label is presentation-only and is not stored in the model transcript.
 
-One task remains selected to receive the next normal message, but other named tasks may keep running concurrently. `/session new <name>` shares the configured workspace, while `/session new <name> --worktree` creates an isolated checkout for that task under the daemon workspace's `.qwen/worktrees/` directory. The daemon verifies the persisted worktree owner before reopening the task after a restart; a missing, changed, or foreign ownership record fails closed instead of silently moving the task into the shared workspace. Creating or selecting another task does not cancel or retarget earlier work, and late results retain their originating task label. A busy task cannot be closed, but its active prompt can be cancelled with `/session cancel [<name>]` through the existing Channel cancellation behavior. Independently queued turns are not cancelled, but in `collect` dispatch mode any follow-ups buffered behind the cancelled prompt are discarded by that existing behavior. Media preparation is not targeted. Bare permission commands apply only to the selected task, while an explicit request ID can answer an owned inactive task. `/clear`, `/new`, and `/reset` do not replace a selected worktree task; select or create a shared task first. Channel memory remains scoped to the chat rather than to a named task.
+One task remains selected to receive the next normal message, but other named tasks may keep running concurrently. `/session new <name>` shares the configured workspace, while `/session new <name> --worktree` creates an isolated checkout for that task under the daemon workspace's `.qwen/worktrees/` directory. The daemon verifies the persisted worktree owner before reopening the task after a restart; a missing, changed, or foreign ownership record fails closed instead of silently moving the task into the shared workspace. Creating or selecting another task does not cancel or retarget earlier work, and late results retain their originating task label. A busy task cannot be closed, but its active prompt can be cancelled with `/session cancel [<name>]` through the existing Channel cancellation behavior. Independently queued turns are not cancelled, but in `collect` dispatch mode any follow-ups buffered behind the cancelled prompt are discarded by that existing behavior. Media preparation is not targeted. Bare permission commands apply only to the selected task, while an explicit request ID can answer an owned inactive task. `/clear`, `/new`, and `/reset` also work on a selected worktree task: the task gets a fresh conversation while its worktree and files are kept. A busy worktree task refuses the reset until its prompt finishes, and a task whose worktree record was damaged reports the failure without touching files. Channel memory remains scoped to the chat rather than to a named task.
 
 This mode is unavailable in standalone `qwen channel start`, with webhooks, with non-zero channel or group `groupHistoryLimit`, or with Channel loops. If an enabled loop already exists for that channel, the daemon worker refuses to start until the loop is disabled.
 

package/bundled/qc-helper/docs/features/computer-use.md

@@ -25,8 +25,8 @@ Node.js 22 or later and npm are required.
 When first used, the skill runs these commands itself:
 
 ```bash
-qwen mcp add --scope user node-repl npx -y @qwen-code/node-repl-mcp@0.1.2
-npm install --no-save --package-lock=false @qwen-code/cua-sdk@0.20.3
+qwen mcp add --scope user node-repl npx -y @qwen-code/node-repl-mcp@0.1.3
+npm install --no-save --package-lock=false @qwen-code/cua-sdk@0.20.4
 ```
 
 Restart Qwen Code after the MCP server is first added. The skill then resumes
@@ -45,11 +45,13 @@ Ask Qwen Code to use `$computer-use` for the desktop task. After bootstrap, it
 follows the standard Computer Use workflow:
 
 1. discovers the exact application and window;
-2. observes full accessibility state;
-3. acts through current semantic element tokens when possible;
-4. fetches fresh state after every mutation;
-5. verifies the requested result; and
-6. closes the SDK client and resets the REPL.
+2. observes full accessibility state, then accumulates automatic incremental
+   updates into the current state;
+3. performs one or more actions through current semantic element tokens,
+   including unchanged tokens retained across compatible diffs;
+4. fetches the latest state before deciding what to do next; and
+5. closes the SDK client and resets the REPL only when no other persistent
+   state is needed.
 
 The driver is the only component that computes observation diffs. Model code
 uses the typed SDK methods and does not dispatch arbitrary driver tool names.

package/bundled/qc-helper/docs/features/followup-suggestions.md

@@ -2,7 +2,7 @@
 
 Qwen Code can predict what you want to type next and show it as placeholder text in the input area. This feature uses an LLM call to analyze the conversation context and generate a natural next step suggestion.
 
-This feature works end-to-end in both the CLI and Web Shell. Generation is automatic and server-side: after each completed turn the daemon emits the suggestion on the session stream (on by default; set `ui.enableFollowupSuggestions` to `false` to opt out), and Web Shell's composer already wires the `useDaemonFollowupSuggestion` hook, so suggestions render and accept with no additional host wiring.
+This feature works end-to-end in both the CLI and Web Shell. Generation is automatic and server-side: after each cleanly completed turn (the daemon's `end_turn` stop reason — a `cancelled`, `refusal`, `max_tokens`, or `max_turn_requests` turn gets none) the daemon emits the suggestion on the session stream (on by default; set `ui.enableFollowupSuggestions` to `false` to opt out), and Web Shell's composer already wires the `useDaemonFollowupSuggestion` hook, so suggestions render and accept with no additional host wiring.
 
 ## How It Works
 
@@ -36,7 +36,7 @@ Suggestions are generated when all of the following conditions are met:
 - The approval mode is not set to `plan`
 - The feature is enabled (on by default — set `ui.enableFollowupSuggestions` to `false` to turn it off)
 
-Suggestions will not appear in non-interactive mode (e.g., headless/SDK mode).
+Suggestions will not appear in the CLI's non-interactive mode (e.g., headless/SDK mode). In the daemon, generation is server-side and runs after every turn that meets the conditions above, so a headless or SDK client that cannot render the suggestion should set `ui.enableFollowupSuggestions` to `false` to avoid the per-turn LLM cost.
 
 Suggestions are automatically dismissed when:
 

package/bundled/qc-helper/docs/features/goals.md

@@ -16,13 +16,17 @@ A Goal keeps Qwen Code working across turns until a stated condition is met. Set
 
 Creating, editing, or resuming a Goal requires a trusted workspace (`/trust`). Headless usage is covered in [Headless Mode](./headless.md#run-a-persistent-goal).
 
+Once a Goal has billed a turn, the footer pill and every status card show what it has spent against the window it is allowed, as `1.2k/30.0m`. The figure counts the model calls the Goal makes in its own turns; subagents and the verifier's own checks are not included. The window is set by [`model.goalTokenBudget`](../configuration/settings.md); resuming a Goal that has spent its window grants another one on top of what it has already spent, so the figure reads `30.0m/60.0m` rather than starting over. A Goal with no budget shows only what it has spent. A Goal that has not billed a turn yet shows no figures at all.
+
+A long Goal periodically compresses the evidence it has recorded into checkpoint claims with a side model call, so later turns and the verifier still have it to cite. That call is bounded by [`model.goalCheckpointTimeoutSeconds`](../configuration/settings.md), 180 seconds by default; a checkpoint that does not finish in time is abandoned as an inconclusive check — the checkpoint stall streak is preserved rather than incremented — and a later turn retries it. The call is streamed, so the per-request transport timeout bounds only connect and first response, and the ceiling itself stops at the stream guards' 15-minute lifetime cap because past that the guard, not the setting, ends the call. That 15-minute limit on the setting is fixed, and raising the stream guard's own cap does not lift it.
+
 ## Interrupting a Goal
 
 Cancelling a Goal turn pauses the Goal. Press Esc while the model is answering or while its tools are still running, and the turn stops, the Goal moves to `paused`, and the card and `/goal` both say why it stopped. Nothing continues until you run `/goal resume`.
 
 Typing a message while a Goal is active does not pause it. Your message runs as the next Goal turn, so use it to steer the work; use `/goal pause` or `/goal clear` to stop it.
 
-Every pause states its reason: that you interrupted it, that you ran `/goal pause`, that the session token limit blocked the next model request, or that the turn failed. A Goal stopped by a limit keeps the reason for that limit instead.
+Every pause states its reason: that you interrupted it, that you ran `/goal pause`, that the session token limit blocked the next model request, that the turn failed, or that three turns in a row recorded nothing the verifier could judge and no proposal — Goal bookkeeping reads (`get_goal`, `update_goal`) do not count as progress. A Goal stopped by a limit keeps the reason for that limit instead.
 
 ## How a Goal is judged
 
@@ -50,6 +54,8 @@ Put these into the objective, in this order:
 
 Keep it to one objective. `/goal set` and `/goal edit` accept any length, but stay roughly under 1,200 characters: the objective is re-sent on every Goal turn. An objective the model proposes through `propose_goal` is capped at 1,500 characters. Both commands collapse newlines to spaces, so number the items rather than relying on line breaks.
 
+`Budget` is an instruction to the model about when to stop and report a blocker. Writing a turn count or time limit in the objective does not configure a runtime timer or change the Goal's token budget.
+
 | Weak                       | Why it fails                                                | Stronger                                                                                                                                                                                                                                |
 | -------------------------- | ----------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
 | make checkout faster       | No threshold, no check.                                     | `Outcome: checkout p95 is below 250 ms. Done when: 1) npm run bench:checkout exits 0 and prints p95 < 250 (paste the line); 2) npm test exits 0. Must not: change the benchmark or skip tests. Budget: stop as blocked after 20 turns.` |
@@ -59,9 +65,15 @@ Keep it to one objective. `/goal set` and `/goal edit` accept any length, but st
 
 ## Let `/goal-draft` write it
 
-`/goal-draft <what you want done>` is a bundled skill that does the above for you. It checks whether the request is a Goal at all, reads the workspace for the real test and lint commands instead of guessing, asks at most one round of multiple-choice questions when the answer changes the check or the scope, drafts the objective in the format above, runs the self-check, and hands it over: in an interactive session it proposes the objective through the `propose_goal` approval dialog described below, otherwise it prints a `/goal set …` line you can run as-is. It never starts the work itself, and nothing is set without your approval.
+`/goal-draft <what you want done>` is a bundled skill that does the above for you. It reads only enough of the workspace to establish the scope and real verification commands, without running tests, building, installing dependencies, or starting services. It asks at most one round of questions when essential choices are unclear, then writes a compact objective, usually with 3–5 completion checks (fewer when enough). Explicit requirements are preserved; it does not add checks just to reach a count.
+
+For an audit, completion means covering the agreed scenarios and reporting evidence, including reproduction steps for confirmed defects. Finding no defects is a valid result. The draft should not invent a minimum number of scenarios, evidence files, exploration rounds, or defects.
+
+If a success criterion, command, input path, or essential decision cannot be established, the skill returns a draft marked "Needs clarification" with `<TODO: …>` items. It does not offer that draft for approval or print a runnable `/goal set` or `/goal edit` command. Nonessential defaults are marked `[ASSUMPTION]`; they do not stand in for missing success criteria.
+
+Once the objective is ready, an interactive terminal session can show the `propose_goal` approval dialog described below. Web Shell and other ACP clients, headless runs, sessions with the tool disabled, and sessions with an active Goal receive a command to run manually instead. The hand-off says that the draft has not been applied. The skill never starts the work itself, and nothing is set without your approval.
 
-Pass an existing objective to tighten it: `/goal-draft all tests pass and the lint is clean`.
+Pass an existing objective to tighten it: `/goal-draft all tests pass and the lint is clean`. For an active Goal, an explicit request to tighten it produces `/goal edit`; a replacement uses `/goal set`. If the intended operation is unclear, the skill includes that choice in its single round of questions.
 
 ### Approve a Goal the model proposes
 

package/bundled/qc-helper/docs/qwen-serve.md

@@ -66,6 +66,12 @@ qwen serve
 
 The default bind is `127.0.0.1:4170`. Bearer auth is **off** and the primary listener is trusted, so any local process that can reach the port can use the full operator API, including executing code as the daemon user. Route-specific workspace trust, session ownership, `X-Qwen-Client-Id`, permission, feature, validation, and resource checks still apply. The daemon registers the current working directory as its primary workspace; use an absolute `--workspace /path/to/dir` to override it, and repeat the flag to register additional isolated runtimes.
 
+For an API-only daemon, disable the Web Shell without narrowing the daemon's REST or SSE API:
+
+```bash
+qwen serve --no-web
+```
+
 **Open the Web Shell UI.** Browse to `http://127.0.0.1:4170/` (or start the daemon with `qwen serve --open` to launch it automatically) for the full browser terminal — chat, diffs, commit history, tool calls, and permission prompts. The UI is served at the daemon root on the same origin as the API. The rest of this guide uses raw HTTP so you can script against the API directly.
 
 For an authenticated single-user launch without manually creating a token, opt in explicitly:
@@ -99,6 +105,18 @@ curl http://127.0.0.1:4170/daemon/status
 The `workspaceCwd` field surfaces the primary compatibility workspace so clients can intentionally omit `cwd` on `POST /session`. Current clients should select a trusted entry from `workspaces[]` and send that entry's `cwd` when targeting a runtime explicitly.
 The `limits.maxPendingPromptsPerSession` field advertises the active per-session prompt admission cap; `null` means the cap is disabled. `limits.maxTotalSessions` advertises the optional daemon-wide fresh-session cap; `null` means unlimited.
 
+### Adjust session live-state polling
+
+Web Shell refreshes workspace session live-state every **5 seconds** by default. To use a different interval, set the daemon environment variable before starting it:
+
+```bash
+QWEN_SESSION_LIVE_STATE_POLL_INTERVAL_MS=10000 qwen serve --web
+```
+
+The value is an integer in milliseconds, from `1000` to `2147483647`. Missing or invalid values fall back to `5000`. The interval applies to all workspaces served by that daemon; restart the daemon and reload any open Web Shell pages after changing it. Local session actions and returning to a visible tab can still refresh immediately. This only changes live-state polling, not full session-catalog polling.
+
+The daemon publishes the effective interval as `sessionLiveStatePollIntervalMs` in `/capabilities`. Web Shell uses that value and falls back to five seconds when connecting to an older daemon that omits it. SDK consumers can read the value when choosing their own polling schedule.
+
 ### Run channels from the daemon
 
 ```bash
@@ -217,7 +235,7 @@ idle daemon returns `initialized: false` with an empty snapshot. Once a
 session is alive they switch to `initialized: true` and surface the real
 state.
 
-To update workspace Skill settings by name, call `POST /workspace/skills/:name/enable` with `{ "enabled": true | false }` after checking the `workspace_skill_settings_toggle` capability. To change several names, check `workspace_skill_settings_batch_toggle` and call `POST /workspace/skills/enable` with `{ "skillNames": ["review", "deploy"], "enabled": false }`; it processes every structurally valid name together, persists all resulting declaration changes in at most one locked settings write, and refreshes active ACP sessions once when anything changed. These routes write workspace `skills.disabled` and `skills.enabled` without consulting the loaded Skill catalog, so names may be disabled before installation or while their Extension is inactive. Enabling removes a matching workspace disable and records an explicit `skills.enabled` opt-in, even before installation, so this entry can override an Extension's internal Skill disablement. Repeating the same declaration is a no-op (`changed: false`). Their paths and request bodies are unchanged; the settings-specific capabilities replace the retired catalog-validated Skill toggle tags. The batch `errors` array remains for wire compatibility and is empty for structurally valid names. A hard `skills.disabled` entry inherited from a higher scope remains authoritative for effective availability, but does not block the workspace from recording or removing its own declaration. Skill status cells expose `disabledReason` (`hard`, `default`, or `inactive_extension`) and an optional `lockedScope`. Untrusted workspace writes are still rejected. A `deferred` response means no child was live at the liveness check or a changed request lost its child/session during the required refresh; when `changed` is true, the persisted declaration applies when a child starts. Whether a declaration actually changed is reported by `changed` (on each result for a batch request). `skills.disabled` disables both manual and model use, unlike `disable-model-invocation: true`, which keeps direct `/skill-name` invocation available. For V2 Extension batches, check `extension_batch_activation_v2`: `PUT /extensions/activation` changes global defaults, while `PUT /workspaces/:workspace/extensions/activation` changes exact overrides for the selected workspace and accepts `"inherit"` to clear them. Both accept names in `extensionNames`; `enabled` and `disabled` may be declared before installation, while `inherit` for an unknown name is a no-op. Each request returns one operation to poll.
+To update workspace Skill settings by name, call `POST /workspace/skills/:name/enable` with `{ "enabled": true | false }` after checking the `workspace_skill_settings_toggle` capability. To change several names, check `workspace_skill_settings_batch_toggle` and call `POST /workspace/skills/enable` with `{ "skillNames": ["review", "deploy"], "enabled": false }`; it processes every structurally valid name together, persists all resulting declaration changes in at most one locked settings write, and refreshes active ACP sessions once when anything changed. These routes write workspace `skills.disabled` and `skills.enabled` without consulting the loaded Skill catalog, so names may be disabled before installation or while their Extension is inactive. Enabling removes a matching workspace disable and records an explicit `skills.enabled` opt-in, even before installation, so this entry can override an Extension's internal Skill disablement. Repeating the same declaration is a no-op (`changed: false`). Their paths and request bodies are unchanged; the settings-specific capabilities replace the retired catalog-validated Skill toggle tags. The batch `errors` array remains for wire compatibility and is empty for structurally valid names. A hard `skills.disabled` entry inherited from a higher scope remains authoritative for effective availability, but does not block the workspace from recording or removing its own declaration. Skill status cells expose `disabledReason` (`hard`, `default`, or `inactive_extension`) and an optional `lockedScope`. Untrusted workspace writes are still rejected. A `deferred` response means no child was live at the liveness check or a changed request lost its child/session during the required refresh; when `changed` is true, the persisted declaration applies when a child starts. Whether a declaration actually changed is reported by `changed` (on each result for a batch request). `skills.disabled` disables both manual and model use, unlike `disable-model-invocation: true`, which keeps direct `/skill-name` invocation available. For V2 Extension batches, check `extension_batch_activation_v2`: `PUT /extensions/activation` changes global defaults, while `PUT /workspaces/:workspace/extensions/activation` changes exact overrides for the selected workspace and accepts `"inherit"` to clear them. Both accept names in `extensionNames`; `enabled` and `disabled` may be declared before installation, while `inherit` for an unknown name is a no-op. Each request returns one operation to poll. When `extension_activation_explicit_refresh` is advertised, that operation finishes after the activation policy is committed and does not directly refresh active sessions. To apply it immediately, submit the independent primary or workspace-qualified Extension refresh after activation succeeds. Without that explicit refresh, other workspaces can continue using the previous activation for up to the next 30-second generation-reconciler pass; failed reconciliation is retried by later passes.
 
 `GET /workspace/env` and `GET /workspace/preflight` always answer with
 `initialized: true` regardless of ACP state. `env` never consults ACP

package/chunks/{MaxSizedBox-IYIQ43IZ.js → MaxSizedBox-ZZJT3PJF.js}

@@ -14,34 +14,34 @@ import "./chunk-47ECGEJC.js";
 import "./chunk-2MIN6GRR.js";
 import "./chunk-QHTIBUWB.js";
 import "./chunk-RKUWKYED.js";
-import "./chunk-TXAEXF2B.js";
+import "./chunk-BL6B2QS2.js";
 import "./chunk-GELRJXE2.js";
 import "./chunk-32CM56LO.js";
-import "./chunk-C7M445SS.js";
+import "./chunk-G5QLLD53.js";
 import "./chunk-2EKVPSIJ.js";
 import "./chunk-LJZSMWOH.js";
-import "./chunk-E4VX6LXB.js";
-import "./chunk-RSU3I6UL.js";
+import "./chunk-YZTGGCEE.js";
+import "./chunk-DCPRCDSR.js";
 import "./chunk-DJXSOEFB.js";
-import "./chunk-KTLT7VCX.js";
+import "./chunk-LN3WBOKU.js";
 import "./chunk-J3VZF2AL.js";
 import "./chunk-OWCFKIFQ.js";
 import "./chunk-ZPJWUGCS.js";
 import "./chunk-5Z4FCEPY.js";
 import "./chunk-BUQN5LTI.js";
-import "./chunk-VU7O7CGQ.js";
-import "./chunk-SD7Y2PMC.js";
+import "./chunk-XDNFODER.js";
+import "./chunk-XI7RST4D.js";
 import "./chunk-VNOVK4I7.js";
-import "./chunk-TSLRORQR.js";
+import "./chunk-43CI6YWJ.js";
 import "./chunk-GOFAQQZA.js";
-import "./chunk-3K65MUKD.js";
+import "./chunk-65I7S4Z3.js";
 import "./chunk-6HUXPLB5.js";
 import "./chunk-TWPJO254.js";
 import "./chunk-CQ35AJ4Z.js";
 import "./chunk-YHDGABDC.js";
 import "./chunk-LYT2OU7D.js";
 import "./chunk-B54PFQS5.js";
-import "./chunk-ERMAXPXA.js";
+import "./chunk-HIXUUCGY.js";
 import "./chunk-6PVPNMXU.js";
 import "./chunk-565U2ANU.js";
 import "./chunk-FDOGGKAA.js";
@@ -59,26 +59,26 @@ import "./chunk-BF3RUIVP.js";
 import "./chunk-JX6XHPTX.js";
 import "./chunk-CLKE4IY3.js";
 import "./chunk-ZSTCM3MX.js";
-import "./chunk-NXWYCSPL.js";
+import "./chunk-SOA4HKRJ.js";
 import "./chunk-MLXTMF7H.js";
-import "./chunk-OFB36ZBA.js";
+import "./chunk-3LPJ776W.js";
 import "./chunk-3CZ2BQV6.js";
 import "./chunk-PQEISIKS.js";
-import "./chunk-3K456UJF.js";
+import "./chunk-VF6D6EGV.js";
 import "./chunk-H3Q3RSKZ.js";
 import "./chunk-S6LOFUVP.js";
 import "./chunk-NAVJD2PQ.js";
-import "./chunk-UKADFFL2.js";
-import "./chunk-EJNYBDYC.js";
+import "./chunk-OFVAS4AR.js";
+import "./chunk-HNLMYDQE.js";
 import "./chunk-QHMLYMMS.js";
 import "./chunk-CFKIH3D3.js";
-import "./chunk-2LD5U7Q3.js";
+import "./chunk-6YEOCHSE.js";
 import "./chunk-DJ2GSRLV.js";
-import "./chunk-W4LL5RZO.js";
-import "./chunk-3UMWOKJC.js";
+import "./chunk-4ALNJDHL.js";
+import "./chunk-NOO4QFXM.js";
 import "./chunk-KFFCDLKV.js";
 import "./chunk-7OCIQNKX.js";
-import "./chunk-WQBR7LN5.js";
+import "./chunk-OIPUQE3S.js";
 import "./chunk-5ETULJLP.js";
 import "./chunk-XBVNNDPK.js";
 import "./chunk-VGC4I5JJ.js";
@@ -88,7 +88,7 @@ import "./chunk-HD7O6WLV.js";
 import "./chunk-WZAD4ZNJ.js";
 import "./chunk-FPGTNKCP.js";
 import "./chunk-TIGXX4PA.js";
-import "./chunk-PLUAIHZO.js";
+import "./chunk-DTB5BXRG.js";
 import "./chunk-XFFRI3WM.js";
 import "./chunk-4HOEU2OR.js";
 import "./chunk-HHJLM3WQ.js";

package/chunks/{StandaloneSessionPicker-AWB2OHX6.js → StandaloneSessionPicker-DIOSZTMX.js}

@@ -4,16 +4,16 @@ import {
   ConfigContext,
   SessionPicker,
   SettingsContext
-} from "./chunk-B5FF3LRF.js";
-import "./chunk-KP5QK3FB.js";
-import "./chunk-T7TP5UQL.js";
+} from "./chunk-WIRYFL2L.js";
+import "./chunk-VH764G6B.js";
+import "./chunk-ULY4ISY2.js";
 import {
   KeypressProvider
-} from "./chunk-AWDF462I.js";
-import "./chunk-VYCJITND.js";
-import "./chunk-I67KJGM6.js";
+} from "./chunk-5GD7LYOH.js";
+import "./chunk-QJAFSFYA.js";
+import "./chunk-W3ONSAYO.js";
 import "./chunk-3SH53ANB.js";
-import "./chunk-HY3DXYZK.js";
+import "./chunk-UYDQYDW2.js";
 import "./chunk-4WGODMVR.js";
 import "./chunk-KW7NOTN6.js";
 import "./chunk-2UWQX4FP.js";
@@ -30,59 +30,59 @@ import {
 import {
   require_react
 } from "./chunk-5QWWOFGG.js";
-import "./chunk-YLFICBYK.js";
-import "./chunk-22QOQKG4.js";
+import "./chunk-VEQBVJYH.js";
+import "./chunk-CG2PDIGD.js";
 import "./chunk-WXFCI3O5.js";
 import "./chunk-XQ4RDO5B.js";
 import "./chunk-EKTCKZV5.js";
-import "./chunk-37SOBIA3.js";
+import "./chunk-ERXNTINK.js";
 import "./chunk-47ECGEJC.js";
 import "./chunk-2MIN6GRR.js";
 import "./chunk-QHTIBUWB.js";
 import "./chunk-57OAHC2Y.js";
-import "./chunk-UTVIIA7N.js";
-import "./chunk-RUMSY4ES.js";
-import "./chunk-QW7BUOSI.js";
+import "./chunk-NVS4Z6GT.js";
+import "./chunk-Q2F43WTJ.js";
+import "./chunk-MWEF5MUK.js";
 import "./chunk-RKUWKYED.js";
 import "./chunk-BW4333PP.js";
 import "./chunk-IDS7MSUP.js";
-import "./chunk-LD53HMPV.js";
+import "./chunk-CRZBDVP2.js";
 import "./chunk-5EJZE3FP.js";
-import "./chunk-4OCYWXKF.js";
-import "./chunk-NUQFUXOG.js";
-import "./chunk-GEV66YGE.js";
+import "./chunk-Y6ZWXM44.js";
+import "./chunk-QTNCGZHQ.js";
+import "./chunk-7RXOEUFF.js";
 import "./chunk-NPQ5ZKRP.js";
 import "./chunk-MR3PXB6E.js";
-import "./chunk-TXAEXF2B.js";
+import "./chunk-BL6B2QS2.js";
 import "./chunk-GELRJXE2.js";
 import "./chunk-32CM56LO.js";
-import "./chunk-C7M445SS.js";
+import "./chunk-G5QLLD53.js";
 import "./chunk-2EKVPSIJ.js";
 import "./chunk-LJZSMWOH.js";
-import "./chunk-E4VX6LXB.js";
-import "./chunk-RSU3I6UL.js";
+import "./chunk-YZTGGCEE.js";
+import "./chunk-DCPRCDSR.js";
 import "./chunk-DJXSOEFB.js";
-import "./chunk-KTLT7VCX.js";
+import "./chunk-LN3WBOKU.js";
 import "./chunk-J3VZF2AL.js";
 import "./chunk-OWCFKIFQ.js";
 import "./chunk-ZPJWUGCS.js";
 import "./chunk-5Z4FCEPY.js";
 import "./chunk-BUQN5LTI.js";
-import "./chunk-VU7O7CGQ.js";
-import "./chunk-SD7Y2PMC.js";
+import "./chunk-XDNFODER.js";
+import "./chunk-XI7RST4D.js";
 import "./chunk-VNOVK4I7.js";
 import {
   SessionService
-} from "./chunk-TSLRORQR.js";
+} from "./chunk-43CI6YWJ.js";
 import "./chunk-GOFAQQZA.js";
-import "./chunk-3K65MUKD.js";
+import "./chunk-65I7S4Z3.js";
 import "./chunk-6HUXPLB5.js";
 import "./chunk-TWPJO254.js";
 import "./chunk-CQ35AJ4Z.js";
 import "./chunk-YHDGABDC.js";
 import "./chunk-LYT2OU7D.js";
 import "./chunk-B54PFQS5.js";
-import "./chunk-ERMAXPXA.js";
+import "./chunk-HIXUUCGY.js";
 import "./chunk-6PVPNMXU.js";
 import "./chunk-565U2ANU.js";
 import "./chunk-FDOGGKAA.js";
@@ -100,28 +100,28 @@ import "./chunk-BF3RUIVP.js";
 import "./chunk-JX6XHPTX.js";
 import "./chunk-CLKE4IY3.js";
 import "./chunk-ZSTCM3MX.js";
-import "./chunk-NXWYCSPL.js";
+import "./chunk-SOA4HKRJ.js";
 import "./chunk-MLXTMF7H.js";
-import "./chunk-OFB36ZBA.js";
+import "./chunk-3LPJ776W.js";
 import {
   getGitBranch
 } from "./chunk-3CZ2BQV6.js";
 import "./chunk-PQEISIKS.js";
-import "./chunk-3K456UJF.js";
+import "./chunk-VF6D6EGV.js";
 import "./chunk-H3Q3RSKZ.js";
 import "./chunk-S6LOFUVP.js";
 import "./chunk-NAVJD2PQ.js";
-import "./chunk-UKADFFL2.js";
-import "./chunk-EJNYBDYC.js";
+import "./chunk-OFVAS4AR.js";
+import "./chunk-HNLMYDQE.js";
 import "./chunk-QHMLYMMS.js";
 import "./chunk-CFKIH3D3.js";
-import "./chunk-2LD5U7Q3.js";
+import "./chunk-6YEOCHSE.js";
 import "./chunk-DJ2GSRLV.js";
-import "./chunk-W4LL5RZO.js";
-import "./chunk-3UMWOKJC.js";
+import "./chunk-4ALNJDHL.js";
+import "./chunk-NOO4QFXM.js";
 import "./chunk-KFFCDLKV.js";
 import "./chunk-7OCIQNKX.js";
-import "./chunk-WQBR7LN5.js";
+import "./chunk-OIPUQE3S.js";
 import "./chunk-5ETULJLP.js";
 import "./chunk-XBVNNDPK.js";
 import "./chunk-VGC4I5JJ.js";
@@ -131,7 +131,7 @@ import "./chunk-HD7O6WLV.js";
 import "./chunk-WZAD4ZNJ.js";
 import "./chunk-FPGTNKCP.js";
 import "./chunk-TIGXX4PA.js";
-import "./chunk-PLUAIHZO.js";
+import "./chunk-DTB5BXRG.js";
 import "./chunk-XFFRI3WM.js";
 import "./chunk-4HOEU2OR.js";
 import "./chunk-HHJLM3WQ.js";
@@ -144,7 +144,7 @@ import "./chunk-G6UUOCUT.js";
 import "./chunk-IZ2U57NY.js";
 import "./chunk-MWIO7MF6.js";
 import "./chunk-ZAFYHRVY.js";
-import "./chunk-HPE4LEWX.js";
+import "./chunk-JDPBJIKI.js";
 import {
   writeStdoutLine
 } from "./chunk-7FA2II6K.js";

package/chunks/{acp-startup-profiler-BAL4LJTN.js → acp-startup-profiler-KEU6VAYR.js}

@@ -9,8 +9,8 @@ import {
   markAcpStartup,
   recordAcpConfigStartupEvent,
   resetAcpStartupProfilerForTesting
-} from "./chunk-IMWCUWQT.js";
-import "./chunk-Z6KFLEG7.js";
+} from "./chunk-J3TJH52D.js";
+import "./chunk-PSPAM24S.js";
 import "./chunk-5O2XNYP6.js";
 import "./chunk-J2S4EL5Y.js";
 export {