jupyterlab_ai_code_assistants_extension 1.2.1 → 1.2.5

package/README.md

@@ -35,8 +35,8 @@ Chat-panel extensions re-implement the agent loop and trail the real tool. This
 - **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 and Gemini) behind the same menu item
 - **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 and Gemini 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
-- **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. Use it rather than the tab menu's own Clear, which will not release a stored colour. A Codex or Kimi conversation that has never been resumed cannot be tracked yet, so a colour set on its tab is not kept
+- **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 and Gemini 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
 - **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

package/lib/core/colour.d.ts

@@ -2,8 +2,10 @@ import { ServerConnection } from '@jupyterlab/services';
 import { ColourSource, ISession } from './types';
 /** The colour vocabulary of `jupyterlab_colourful_tab_extension`, in its own
  * order - that extension owns the tab CSS and these six ids; this module only
- * feeds it one of them. The order is load-bearing: its localStorage records a
- * user's menu choice as an INDEX into this list. */
+ * feeds it one of them. The order is still load-bearing, for `fnv1aColour`:
+ * both halves of this extension index into this list to derive a tint, so a
+ * reorder repaints every derived tab and makes the browser and the server
+ * disagree about the same conversation until the Python list moves with it. */
 export declare const TAB_COLOUR_IDS: readonly string[];
 /** Map a conversation id onto one of the six colour ids. FNV-1a (32-bit) - a
  * stable string hash with good avalanche on short hex-ish ids; `Math.imul`
@@ -19,14 +21,6 @@ export declare const TAB_COLOUR_IDS: readonly string[];
  * the next time somebody rewrites either loop. Every real conversation id is
  * ASCII, where all three readings coincide, so no existing tab changes colour. */
 export declare function fnv1aColour(sessionId: string): string;
-/** Colour the user set by hand on a terminal tab, or null.
- *
- * The colourful-tab extension stores its right-click menu choices as
- * `{ "terminal:<session name>": <index into TAB_COLOUR_IDS> }`. Reading it is
- * what makes "set the colour on the tab" register as the conversation's
- * colour - for every assistant, including one whose CLI has a colour concept
- * of its own. */
-export declare function readUserSetTabColour(terminalName: string): string | null;
 /** Resolve the ladder for one conversation. `userSet` is this extension's own
  * store, `native` the conversation's own colour (only ever populated by a
  * `native` provider). */
@@ -115,8 +109,8 @@ export declare class ColourStore {
      * `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
-     * `reconcileColours` gates its paint on.
+     * 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`.
      *
      * The cache is written only once the server has confirmed. Writing it
      * eagerly and undoing that on failure looks cheaper and is not: nothing here

package/lib/core/colour.js

@@ -12,8 +12,10 @@
 import { requestProvider } from './request';
 /** The colour vocabulary of `jupyterlab_colourful_tab_extension`, in its own
  * order - that extension owns the tab CSS and these six ids; this module only
- * feeds it one of them. The order is load-bearing: its localStorage records a
- * user's menu choice as an INDEX into this list. */
+ * feeds it one of them. The order is still load-bearing, for `fnv1aColour`:
+ * both halves of this extension index into this list to derive a tint, so a
+ * reorder repaints every derived tab and makes the browser and the server
+ * disagree about the same conversation until the Python list moves with it. */
 export const TAB_COLOUR_IDS = [
     'rose',
     'peach',
@@ -22,10 +24,6 @@ export const TAB_COLOUR_IDS = [
     'sky',
     'lavender'
 ];
-/** Key `jupyterlab_colourful_tab_extension` persists menu-set tab colours
- * under, and the `terminal:<session name>` shape of its entries. Read only -
- * this module never writes into another extension's storage. */
-const TAB_COLOUR_STORAGE_KEY = 'jupyterlab-colourful-tab-colours';
 /** Map a conversation id onto one of the six colour ids. FNV-1a (32-bit) - a
  * stable string hash with good avalanche on short hex-ish ids; `Math.imul`
  * keeps the multiplication in 32-bit integer semantics. The same id always
@@ -47,33 +45,6 @@ export function fnv1aColour(sessionId) {
     }
     return TAB_COLOUR_IDS[(hash >>> 0) % TAB_COLOUR_IDS.length];
 }
-/** Colour the user set by hand on a terminal tab, or null.
- *
- * The colourful-tab extension stores its right-click menu choices as
- * `{ "terminal:<session name>": <index into TAB_COLOUR_IDS> }`. Reading it is
- * what makes "set the colour on the tab" register as the conversation's
- * colour - for every assistant, including one whose CLI has a colour concept
- * of its own. */
-export function readUserSetTabColour(terminalName) {
-    var _a;
-    try {
-        const raw = window.localStorage.getItem(TAB_COLOUR_STORAGE_KEY);
-        if (!raw) {
-            return null;
-        }
-        const parsed = JSON.parse(raw);
-        const index = parsed[`terminal:${terminalName}`];
-        if (typeof index !== 'number') {
-            return null;
-        }
-        return (_a = TAB_COLOUR_IDS[index]) !== null && _a !== void 0 ? _a : null;
-    }
-    catch (_err) {
-        // localStorage unavailable, or another extension's schema changed under
-        // us - no user colour is a valid answer, a thrown error is not.
-        return null;
-    }
-}
 /** Resolve the ladder for one conversation. `userSet` is this extension's own
  * store, `native` the conversation's own colour (only ever populated by a
  * `native` provider). */
@@ -250,8 +221,8 @@ export class ColourStore {
      * `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
-     * `reconcileColours` gates its paint on.
+     * 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`.
      *
      * The cache is written only once the server has confirmed. Writing it
      * eagerly and undoing that on failure looks cheaper and is not: nothing here

package/lib/core/panel.d.ts

@@ -147,11 +147,14 @@ export declare class AssistantSessionsPanel extends Widget {
      * until the next reconcile tick. One request for the whole set, so a release
      * is never left half applied.
      *
-     * The colourful-tab extension's own menu record is normally consumed when
-     * the colour is captured, so this is the release. A tab closed in the window
-     * between the capture write and the paint keeps that record, and reopening
-     * the terminal re-captures the colour - rare, and visible rather than
-     * silent, since the tab still wears it. */
+     * The colourful-tab extension persists nothing for a tab this extension has
+     * claimed, so it holds no record of the released colour to drop alongside
+     * the store entry: dropping that entry and repainting is the whole of it.
+     * Clearing the colour on the tab itself reaches the same place by the other
+     * route - the
+     * companion reports it as a choice with no colour and the handler forgets
+     * 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.
      *

package/lib/core/panel.js

@@ -1060,11 +1060,14 @@ export class AssistantSessionsPanel extends Widget {
      * until the next reconcile tick. One request for the whole set, so a release
      * is never left half applied.
      *
-     * The colourful-tab extension's own menu record is normally consumed when
-     * the colour is captured, so this is the release. A tab closed in the window
-     * between the capture write and the paint keeps that record, and reopening
-     * the terminal re-captures the colour - rare, and visible rather than
-     * silent, since the tab still wears it. */
+     * The colourful-tab extension persists nothing for a tab this extension has
+     * claimed, so it holds no record of the released colour to drop alongside
+     * the store entry: dropping that entry and repainting is the whole of it.
+     * Clearing the colour on the tab itself reaches the same place by the other
+     * route - the
+     * companion reports it as a choice with no colour and the handler forgets
+     * 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. */
     async _resetColours(sessionIds) {
         if (!(await this._colours.forget(sessionIds))) {
             // No refresh afterwards: `_fetch` clears the inline error, and a failure
@@ -1961,11 +1964,13 @@ export class AssistantSessionsPanel extends Widget {
                 }
             }
         });
-        // The only way back out of a hand-set tab colour. The colourful-tab
-        // extension's own Clear touches its storage and the tab's classes, neither
-        // of which this extension reads once the colour is in its store, so
-        // without this item the override would be permanent - and on a native
-        // assistant that means `/color` silently never showing again.
+        // The way back out of a hand-set tab colour for a conversation whose
+        // terminal is not open. Clear on the tab itself is reported by the
+        // colourful-tab extension as a choice with no colour and does drop the
+        // override, but only for the conversation that terminal is running - so
+        // without this item an override on a branch with no tab open would be
+        // permanent, and on a native assistant that means `/color` silently never
+        // showing again.
         //
         // It covers every conversation of the row, not just the current one: a
         // terminal opened on a branch files its colour under THAT branch, and this

package/lib/core/terminals.d.ts

@@ -87,10 +87,16 @@ export declare class TerminalManager {
      *
      * Each terminal's conversation is re-resolved on every pass rather than
      * taken from the launch cache, which pins the launch-time conversation and
-     * goes stale on an in-place switch. On the way through, a colour the user
-     * set by hand on the tab is written back into this provider's colour store,
-     * which is what makes "set the tab colour" mean "this conversation's colour"
-     * even for an assistant whose CLI has no colour concept.
+     * goes stale on an in-place switch.
+     *
+     * It touches this extension's own store and nothing else - no browser
+     * storage, no other extension's records, and that must stay true. The colour
+     * the user picks on a tab arrives as a signal instead (`_onColourChanged`);
+     * reading it back out of the companion's storage is what made a recycled
+     * terminal name hand a dead terminal's colour to a live conversation,
+     * permanently, at the top of the ladder. The only write this pass makes is a
+     * choice that signal already delivered, whose conversation was unreadable at
+     * the time - see `_pendingChoices`.
      */
     reconcileColours(): Promise<void>;
     /** Effective colour of one conversation as the cache currently reads it, for
@@ -109,6 +115,86 @@ export declare class TerminalManager {
      * another extension, both are called as `void`, and turning tab colouring
      * off must not spill an unhandled rejection. */
     clearColours(): Promise<void>;
+    /** The user picked a colour on a tab, or cleared one.
+     *
+     * The slot itself stays synchronous - Lumino ignores what a slot returns, so
+     * an async slot's rejection would surface as an unhandled one.
+     */
+    private _onColourChanged;
+    /** File one choice against the conversation the coloured terminal is
+     * actually running.
+     *
+     * Only a terminal this provider owns, and only one whose conversation the
+     * server READ from the running process. A widget whose conversation cannot
+     * be read is never filed against one guessed from its folder: a project has
+     * many conversations, and filing the user's colour under the wrong one
+     * recolours a conversation they never touched. That choice waits instead,
+     * but only where the probe named the terminal - see `_pendingChoices`.
+     */
+    private _captureColour;
+    /** Write one choice into this extension's own store - a colour for a pick, a
+     * forget for a clear - and answer whether the store now holds it.
+     *
+     * Nothing is painted for a refused write, at either call site. The tab is
+     * claimed, so the companion holds no record of this choice and there is
+     * nothing in the store either - every colour this extension could paint is
+     * the conversation's PREVIOUS one, which is what the pick was meant to
+     * replace. What the user sees instead is the class the companion's menu put
+     * on the tab element, and that survives only until the next tab switch:
+     * Lumino rebuilds a tab's class attribute from the widget title whenever the
+     * current tab changes, and the title still carries that previous colour. So
+     * the choice is lost either way - the warning is what makes it something
+     * other than silent. */
+    private _fileChoice;
+    /** Tell the companion this tab's colour is ours to persist.
+     *
+     * Once per terminal, not once per pass - the pass runs every 30 seconds and
+     * each claim is a disposable the companion has to hold. A widget id is a
+     * safe key for that: JupyterLab mints one uuid per widget (`id-<uuid4>`,
+     * verified against 4.6.3 on 2026-09-04) and never hands it to a second
+     * widget, so a claim held under an id belongs to the widget still wearing
+     * it. Terminal NAMES are what terminado recycles - which is why the
+     * companion fingerprints what it persists, and why nothing here keys on a
+     * name.
+     */
+    private _claimTab;
+    /** Give up every claim this pass did not renew.
+     *
+     * A claim says "this extension draws this tab and records what you pick on
+     * it", and that stops being true the moment the terminal stops probing as
+     * this assistant's - it exited, another assistant took the pty, or the
+     * widget is gone from the tracker altogether. Holding on would leave a
+     * colour picked on that tab persisted by nobody, and the map growing by one
+     * entry per closed terminal for the life of the page.
+     *
+     * A terminal whose probe merely failed is released too, since an unreadable
+     * terminal is not evidence of ownership. The next pass that reads it claims
+     * it again, and re-claiming costs nothing visible: a claim suppresses the
+     * companion's persistence and narrows its repaint to a fingerprint-verified
+     * entry, deleting nothing it stored before, and the next paint puts this
+     * conversation's colour back. */
+    private _releaseLapsedClaims;
+    private _releaseClaims;
+    /** Forget the choices whose premise no longer holds.
+     *
+     * A choice is held on one answer only - this assistant's terminal, its
+     * conversation not readable yet - and it stops being a choice about anything
+     * the moment either half of that stops being true.
+     *
+     * The terminal CLOSED. A pending choice is about one tab and must not outlive
+     * it. A widget id is never handed to a second widget, so the record could
+     * never be filed again - what it would do is hold that widget's id, one entry
+     * per closed terminal, for the life of the page.
+     *
+     * The terminal is no longer THIS ASSISTANT'S, per an answer the server
+     * actually gave. The conversation the pick was made under has ended, and the
+     * assistant coming back in the same terminal starts a NEW one - so a choice
+     * kept across that gap is filed against a conversation the user never picked
+     * a colour for, as hand-set, at the top of the ladder. A probe that failed is
+     * deliberately not evidence here: it says only that the server did not
+     * answer, and discarding the pick on that basis loses a colour the user chose
+     * seconds ago. */
+    private _dropStalePending;
     private _applyColour;
     private _eachAssistantTerminal;
     private _liveTerminals;
@@ -118,13 +204,19 @@ export declare class TerminalManager {
     private readonly _descriptor;
     private readonly _colours;
     private readonly _tracker;
-    private readonly _colourfulTabs;
+    /** The injected colour token narrowed to its ownership API, or null when the
+     * companion is absent or too old to carry it. The only handle on the
+     * companion this class has: with no ownership there is no painting either. */
+    private readonly _tabs;
     private readonly _serverSettings;
+    private readonly _claims;
+    private readonly _pendingChoices;
     private readonly _byProject;
     private readonly _pending;
     private _sessions;
     private _colouredTabs;
     private _colourHandle;
+    private _pass;
     private _disposed;
 }
 export declare namespace TerminalManager {