jupyterlab_ai_code_assistants_extension 1.2.73 → 1.2.99

package/README.md

@@ -29,16 +29,16 @@ Chat-panel extensions re-implement the agent loop and trail the real tool. This
 - **Provider registry** - assistant-specific behaviour lives in one module per assistant behind capability flags; no core file names an assistant, and adding one touches no core file
 - **Joint settings page** - one settings section covering all assistants, with a per-assistant toggle (all on by default); toggling takes effect live, no JupyterLab reload, and a change reaches the other JupyterLab windows of the same browser
 - **Three-section side panel** - Favorites, Recent, and All projects, each scrolling independently
-- **One-click resume** - click a row to jump back into that session in a terminal; an open terminal for the project is reused instead of duplicated. Exception: a Codex or Kimi conversation started with `+`, and a Codex fork, run without an id until the CLI writes one, so a click on that row meanwhile opens a second terminal
+- **One-click resume** - click a row to jump back into that session in a terminal; an open terminal for the project is reused instead of duplicated. Exception: a Kimi or DeepSeek conversation started with `+` runs under an id that never reaches its process command line, so a click on that row while its terminal stays open opens a second terminal. Codex mints the id for a conversation started with `+` and for a fork through its own app-server before the terminal opens, so a click on a Codex row reuses the open terminal instead of opening a second one
 - **File browser follows the opened session** - opening a session moves the JupyterLab file browser to that session's project folder (a setting, on by default); a right-click on a panel header toggles this and moves the panels between the left and right sidebars
 - **Launcher tiles** - every enabled assistant has a tile in an "AI Assistants" section of the JupyterLab Launcher (after Other, under the extension's own robot-head icon); a click opens the assistant in the file browser's current folder, resuming the folder's conversation when one exists and starting a new one otherwise, through the companion `jupyterlab_basic_terminal_extension` (installed automatically). Disable an assistant and its tile goes; disable them all and the section goes with them
 - **Your terminal's `claude -c` follows the panel** (Claude) - switching to a conversation makes plain `claude -c` in that project resume that same conversation, including one that has been compacted, which Claude Code otherwise refuses to continue. Launching repairs a compacted conversation the same way, but only switching moves what `claude -c` picks
 - **Conversation switcher** - a right-click "Switch and Manage Sessions" submenu lists a project's other conversations by name and short id with last-activity time; "Manage Sessions..." opens a searchable popup over the full list with multi-select delete and per-row open and copy-id buttons
-- **Branch session** - fork the current conversation into a new named session via the right-click menu; each assistant forks its own way (Claude's native `--fork-session`, Codex's `codex fork`, server-side copies for Kimi, Gemini and DeepSeek) behind the same menu item
-- **Rename session** - name a conversation from the right-click menu, and the name is written where the assistant itself reads it back: Claude gets the record its own `/rename` writes, Kimi a custom title, Gemini the chat's summary, DeepSeek its title event. The panel shows the name the assistant actually kept. Codex keeps its names in a database this extension only reads, and its CLI has no rename verb, so the item is absent there rather than failing
+- **Branch session** - fork the current conversation into a new named session via the right-click menu; each assistant forks its own way (Claude's native `--fork-session`, Codex's app-server `thread/fork`, server-side copies for Kimi, Gemini and DeepSeek) behind the same menu item
+- **Rename session** - name a conversation from the right-click menu, and the name is written where the assistant itself reads it back: Claude gets the record its own `/rename` writes, Kimi a custom title, Gemini the chat's summary, DeepSeek its title event. The panel shows the name the assistant actually kept. Codex's name is set through Codex's own app-server, so its CLI lists the same name the panel shows
 - **Launch modes under each assistant's own name** - Claude's skip-permissions, Codex's approval bypass, Kimi's `--yolo`, Gemini's YOLO; unsafe variants carry a shield glyph in the launch menus
 - **Coloured terminal tabs** - each session's colour tints its terminal tab via the companion `jupyterlab_colourful_tab_extension` (installed automatically). Claude's own `/color` supplies its default, Kimi derives a stable colour from the conversation id; Codex, Gemini and DeepSeek have no colour of their own until you set one, and a branched session inherits its parent's colour, which it keeps even if the parent's colour later changes or is reset. Tinting needs the companion release that reports the colours you pick and lets another extension own a tab - against an older one this extension tints no tabs at all and says so once, and the companion's own right-click colours keep working as they always did
-- **Your own tab colour wins** - set a colour on a terminal tab and the extension remembers it for that conversation, overriding whatever the assistant chose. `Reset Tab Colour (n)` in the session's right-click menu hands back every colour you set by hand on that project's conversations, and appears once there is one to hand back. Clearing the colour on the tab itself releases it too, for the conversation that terminal is running; `Reset Tab Colour` is the way back for a conversation with no tab open. A Codex or Kimi conversation that has never been resumed cannot be tracked yet, so a colour set on its tab is not kept
+- **Your newest colour choice wins** - set a colour on a terminal tab and the extension remembers it for that conversation, so the tab shows it again when you reopen the conversation. In Claude Code, `/color` is the second way to choose, and whichever you used last wins: a colour picked on the tab after `/color` stays, and running `/color` after a pick takes over again, including `/color` with the same colour or a `/color` reset. `Reset Tab Colour (n)` in the session's right-click menu hands back every colour you set by hand on that project's conversations, and appears once there is one to hand back. Clearing the colour on the tab itself releases it too, for the conversation that terminal is running; `Reset Tab Colour` is the way back for a conversation with no tab open. A Kimi or DeepSeek conversation that has never been resumed cannot be tracked yet, so a colour set on its tab is not kept
 - **Favorites** - star projects you keep coming back to via the right-click menu; favourites from the standalone extensions are migrated on first run
 - **Remove and clean up** - drop a project's history or a project's extra parallel sessions from the right-click menu, confirmation dialog first; removed files honour JupyterLab's "move files to trash" setting
 - **Activity at a glance** - each row shows its last activity in an aligned column; rows active within the last minute light up, rows idle for over a week dim, and rows with parallel conversations show a branch icon with the count
@@ -46,7 +46,7 @@ Chat-panel extensions re-implement the agent loop and trail the real tool. This
 - **Search** - fuzzy filter per panel, toggled by the funnel button
 - **Presentation modes** - label rows by session name or by path relative to the JupyterLab root
 - **Conflict-safe upgrade** - if a retired standalone extension is still installed, its panel wins and this extension stands down for that assistant instead of showing a duplicate
-- **DeepSeek in the browser** - the DeepSeek Harness has no terminal chat; its panel lists the projects under `~/.dsh/sessions` (or `$DSH_HOME`) and `Open Web UI` starts `dsh --profile web --no-open --port 0` in the project's terminal, which prints the URL to open. The conversation is then chosen in the harness's own browser UI; branching and deleting work from the panel as for every other assistant. The URL is on the machine running JupyterLab, so a remote server needs a port forward to reach it
+- **DeepSeek in the terminal** - the DeepSeek Harness ships no terminal chat of its own, so its panel runs the community TUI bundle (`@deepseek-harness-tui/dsh-tui`, mounted as the `tui` profile with `dsh plugin --profile tui add @deepseek-harness-tui/dsh-tui`). Without that profile, a launch is refused before a terminal opens, naming the bundle and the mount command - `dsh tui` itself would instead die in a stack trace that prints that command with a literal `<package>` where the package name goes, and never the bundle's name. The panel lists the projects under `~/.dsh/sessions` (or `$DSH_HOME`), and a click resumes that row's conversation with `dsh tui --resume <id>` in a terminal; a launch with no conversation named starts a new one, whose id the TUI mints itself. Branching and deleting work from the panel as for every other assistant
 - **Auto-disabled when absent** - an assistant whose CLI is not on `PATH` does not show a panel
 - **Open Callback** - when an assistant's login sends your browser to an `http://127.0.0.1:...` link that fails to load, because the login is waiting on the machine running JupyterLab, run `Open Callback` from the command palette and paste the link; the Jupyter server requests it for you, and the popup says whether the login accepted it, then closes by itself 3 seconds later. Only `http` links to that machine's own loopback are accepted
 
@@ -55,6 +55,7 @@ Chat-panel extensions re-implement the agent loop and trail the real tool. This
 - JupyterLab >= 4.6.0
 - Python >= 3.10
 - At least one assistant CLI on `PATH`: `claude`, `codex`, `kimi`, `gemini`, or `dsh` (the DeepSeek Harness)
+- For DeepSeek: the community TUI bundle mounted as the `tui` profile, `dsh plugin --profile tui add @deepseek-harness-tui/dsh-tui` - a DeepSeek launch without it is refused with these words before any terminal opens
 
 ## Install
 

package/lib/core/colour.d.ts

@@ -95,8 +95,7 @@ export declare class ColourStore {
      * times it, not it.
      *
      * An op must never call `load`, `set` or `forget` - it would wait on a chain
-     * that is waiting on it. `inherit` delegates to `set` from OUTSIDE the queue,
-     * which is why it is not itself queued. */
+     * that is waiting on it. */
     private _run;
     /** Open a write against one or more ids. Counted, not flagged: two writes to
      * one id can be queued at once, and a flag would let the first to settle
@@ -106,8 +105,6 @@ export declare class ColourStore {
     private _closeWrite;
     /** Record a colour as this conversation's own. Passing null drops the entry,
      * which is also how a deleted conversation leaves no orphan key behind.
-     * `handSet` false marks it inherited - written on a fork's behalf rather
-     * than chosen on its tab.
      *
      * Answers whether the store now HOLDS the colour, which is what the capture
      * of a colour picked on a tab gates its repaint on - see `_captureColour`.
@@ -121,17 +118,12 @@ export declare class ColourStore {
      * "Did not throw" is not the test - the answer carries the whole store, so
      * it is checked for the value that was just written. A server that accepted
      * the request and then failed to persist it would otherwise be believed. */
-    set(sessionId: string, colour: string | null, handSet?: boolean): Promise<boolean>;
+    set(sessionId: string, colour: string | null): Promise<boolean>;
     /** Drop stored colours - conversations that no longer exist, or overrides
      * the user released. One request for the whole list, so a release is never
      * left half applied. Same contract as `set`: the answer is checked for the
      * absence of every id, and the cache is touched only once it agrees. */
     forget(sessionIds: string[]): Promise<boolean>;
-    /** Copy the parent's EFFECTIVE colour onto a fresh branch, so a branch of a
-     * branch inherits whatever its immediate parent actually shows, user-set
-     * override included. Called at the fork sites, once the new id is known.
-     */
-    inherit(parentColour: string | null, childId: string): Promise<void>;
     private readonly _providerId;
     private readonly _serverSettings;
     private _colours;

package/lib/core/colour.js

@@ -1,7 +1,10 @@
 // Terminal tab tint per conversation.
 //
 // Effective colour, highest wins:
-//   1. user-set     - the write-back store this module keeps, per provider
+//   1. user-set     - the write-back store this module keeps, per provider.
+//                     Only entries the server still holds: it releases a pick
+//                     that the assistant's own later colour command overtook,
+//                     because the newer of the two channels wins (DEF-COLO-306)
 //   2. native       - the conversation's own colour, when the assistant has one
 //   3. derived      - a stable hash of the conversation id
 //   4. none         - no tint
@@ -186,8 +189,7 @@ export class ColourStore {
      * times it, not it.
      *
      * An op must never call `load`, `set` or `forget` - it would wait on a chain
-     * that is waiting on it. `inherit` delegates to `set` from OUTSIDE the queue,
-     * which is why it is not itself queued. */
+     * that is waiting on it. */
     _run(op) {
         const result = this._chain.then(op);
         const settled = () => undefined;
@@ -218,8 +220,6 @@ export class ColourStore {
     }
     /** Record a colour as this conversation's own. Passing null drops the entry,
      * which is also how a deleted conversation leaves no orphan key behind.
-     * `handSet` false marks it inherited - written on a fork's behalf rather
-     * than chosen on its tab.
      *
      * Answers whether the store now HOLDS the colour, which is what the capture
      * of a colour picked on a tab gates its repaint on - see `_captureColour`.
@@ -233,7 +233,7 @@ export class ColourStore {
      * "Did not throw" is not the test - the answer carries the whole store, so
      * it is checked for the value that was just written. A server that accepted
      * the request and then failed to persist it would otherwise be believed. */
-    async set(sessionId, colour, handSet = true) {
+    async set(sessionId, colour) {
         if (!sessionId) {
             return false;
         }
@@ -249,7 +249,7 @@ export class ColourStore {
                     body: JSON.stringify({
                         session_id: sessionId,
                         colour,
-                        hand_set: handSet
+                        hand_set: true
                     })
                 });
                 if (((_a = data.colours) !== null && _a !== void 0 ? _a : {})[sessionId] !== (colour !== null && colour !== void 0 ? colour : undefined)) {
@@ -265,7 +265,7 @@ export class ColourStore {
                     this._colours.delete(sessionId);
                 }
                 this._overrides.delete(sessionId);
-                if (colour && handSet) {
+                if (colour) {
                     this._overrides.add(sessionId);
                 }
                 return true;
@@ -316,14 +316,4 @@ export class ColourStore {
             }
         });
     }
-    /** Copy the parent's EFFECTIVE colour onto a fresh branch, so a branch of a
-     * branch inherits whatever its immediate parent actually shows, user-set
-     * override included. Called at the fork sites, once the new id is known.
-     */
-    async inherit(parentColour, childId) {
-        if (!parentColour || !childId) {
-            return;
-        }
-        await this.set(childId, parentColour, false);
-    }
 }

package/lib/core/modes.d.ts

@@ -15,7 +15,7 @@ export interface IResolvedLaunchMode {
  * do. Otherwise the first switch that is on fires. Every mode is a boolean
  * skip-approval switch, so "on" always means the same thing.
  */
-export declare function resolveLaunchMode(launchModes: ILaunchMode[], values: Record<string, boolean | string>, force?: string): string | undefined;
+export declare function resolveLaunchMode(launchModes: ILaunchMode[], values: Record<string, boolean>, force?: string): string | undefined;
 /**
  * The mode a PLAIN launch would carry right now, as a descriptor entry.
  *
@@ -26,4 +26,4 @@ export declare function resolveLaunchMode(launchModes: ILaunchMode[], values: Re
  * unmarked. Answers the entry rather than the token so the caller can use the
  * assistant's own wording.
  */
-export declare function resolvedLaunchModeEntry(launchModes: ILaunchMode[], values: Record<string, boolean | string>): IResolvedLaunchMode | null;
+export declare function resolvedLaunchModeEntry(launchModes: ILaunchMode[], values: Record<string, boolean>): IResolvedLaunchMode | null;

package/lib/core/panel.d.ts

@@ -37,7 +37,7 @@ export declare class AssistantSessionsPanel extends Widget {
     setRecentLimit(n: number): void;
     /** Current values of this provider's launch modes, read from settings. Each
      * key is an `ILaunchMode.id` in the assistant's own terminology. */
-    setModes(modes: Record<string, boolean | string>): void;
+    setModes(modes: Record<string, boolean>): void;
     setColouredTabs(on: boolean): void;
     /** Whether opening a session moves the file browser to its project folder. */
     setSyncFileBrowser(on: boolean): void;
@@ -45,6 +45,10 @@ export declare class AssistantSessionsPanel extends Widget {
     protected onBeforeHide(_msg: Message): void;
     protected onCloseRequest(msg: Message): void;
     private _buildShell;
+    /** Raise the click-time busy overlay. Counted, because an open and a branch
+     * can overlap; the overlay clears when the last one ends. */
+    private _beginBusy;
+    private _endBusy;
     /** Show / hide the filter input. Hiding also clears the active filter, so
      * the user never returns to an "invisible" filter narrowing the rows. */
     private _toggleFilterBar;
@@ -143,26 +147,13 @@ export declare class AssistantSessionsPanel extends Widget {
     launchHere(cwd?: string): Promise<any>;
     /** Start a brand-new conversation in the file browser's current folder. */
     private _newSession;
-    /**
-     * Branch the active row's current conversation, by the descriptor's
-     * `forkStrategy`.
-     *
-     * The three strategies differ only in who mints the new id and when it
-     * becomes knowable - so the shared part (ask for a name, launch a terminal
-     * on the fork, inherit the parent's tint, surface the branch) lives here
-     * once, and the strategy decides the payload and the discovery.
-     */
+    /** Branch the active row's current conversation. Every `forkStrategy` has
+     * the server mint the fork, so this is the one path. */
     private _branchSession;
-    /** The CLI forks from a flag pair and takes the new id from us, so the fork
-     * is known before it exists. Its store entry is written lazily, on the first
-     * turn, so the branch is watched for rather than expected at once. */
-    private _branchByNativeFlag;
-    /** The CLI owns both the fork verb and the id, so the id has to be
-     * discovered: snapshot the branch ids first, then diff after launch. */
-    private _branchByNativeCommand;
-    /** The assistant has no fork at all: the server copies the store entry and
-     * answers with the new id, so the branch exists before the terminal opens
-     * and one refresh surfaces it - no watcher needed. */
+    /** The server mints the new id and answers with it before the terminal
+     * opens - `server-copy` copies the store entry, `server-native` drives the
+     * assistant's own non-interactive fork path - so one refresh surfaces the
+     * branch. */
     private _branchByServerCopy;
     /** Drop the hand-set colours of this project's conversations and re-tint
      * from the defaults at once, so nothing keeps showing a released colour
@@ -178,26 +169,6 @@ export declare class AssistantSessionsPanel extends Widget {
      * the conversation - but only for a conversation whose terminal is open and
      * probes as this assistant's, which is why this path exists as well. */
     private _resetColours;
-    /** Copy the parent's tint onto a fresh branch.
-     *
-     * A native-colour assistant hands every conversation its own colour, so a
-     * fork already arrives correctly tinted: only what this extension's own
-     * store holds for the parent is inherited there - an entry the parent itself
-     * inherited counts, which is what makes a branch of a branch take what its
-     * parent actually shows. Copying the parent's native tint instead would pin
-     * the fork to it and shadow the fork's own `/color` for good.
-     * Every other assistant inherits the parent's effective colour, which is the
-     * only tint it has. */
-    private _inheritColour;
-    /** Poll fast for a fork whose id we already know, then refresh once. The
-     * panel is never updated before the branch genuinely exists - it cannot list
-     * a store entry that has not been written. */
-    private _watchForBranch;
-    /** Poll fast for a fork whose id the CLI minted: whichever conversation the
-     * snapshot did not hold is the fork. It is then pinned as current (recency
-     * alone would not - the actively written parent overtakes it) and inherits
-     * the parent's tint. */
-    private _watchForNewBranch;
     /** Name the row's current conversation, in the assistant's own store.
      *
      * Only ever offered where the descriptor says the assistant keeps a name
@@ -273,9 +244,7 @@ export declare class AssistantSessionsPanel extends Widget {
     private _variantSuffix;
     /** Whether a forced variant would build the launch the plain item already
      * builds - a mode left on in settings makes the plain item carry it, so the
-     * variant beside it would be a second entry for one outcome. Only a boolean
-     * variant can match: a forced token is the bare mode id, so an enum sitting
-     * on a widening value is a launch no variant duplicates. */
+     * variant beside it would be a second entry for one outcome. */
     private _buildsSameLaunch;
     /** The glyph, only where the mode WIDENS what runs without asking. */
     private _variantIcon;
@@ -337,6 +306,9 @@ export declare class AssistantSessionsPanel extends Widget {
     private readonly _removingPaths;
     private _bodyEl;
     private _loadingEl;
+    private _busyEl;
+    private _busyTextEl;
+    private _busyCount;
     private _errorEl;
     private _refreshBtn;
     private _filterBtn;