clikernel 0.2.2__tar.gz → 0.2.3__tar.gz

{clikernel-0.2.2 → clikernel-0.2.3}/CHANGELOG.md

@@ -2,6 +2,16 @@
 
 <!-- do not remove -->
 
+## 0.2.3
+
+### New Features
+
+- Auto-create a conversation-scoped kernel on execute when none is connected, stopped at exit or on the next connect ([#35](https://github.com/AnswerDotAI/clikernel/issues/35))
+- Add MAXLEN constant (180) for traceback line truncation, replacing hardcoded 120 ([#34](https://github.com/AnswerDotAI/clikernel/issues/34))
+- require shell tool over subprocess/os.system for shell commands ([#33](https://github.com/AnswerDotAI/clikernel/pull/33)), thanks to [@ncoop57](https://github.com/ncoop57)
+- document %cd ~ expansion as the idiomatic way to change kernel directory ([#30](https://github.com/AnswerDotAI/clikernel/pull/30)), thanks to [@ncoop57](https://github.com/ncoop57)
+
+
 ## 0.2.2
 
 ### New Features

{clikernel-0.2.2/clikernel.egg-info → clikernel-0.2.3}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: clikernel
-Version: 0.2.2
+Version: 0.2.3
 Summary: Serve persistent Jupyter kernels to LLMs as concise text, over MCP or a plain stream protocol
 Author: clikernel contributors
 License: Apache-2.0
@@ -12,7 +12,7 @@ Requires-Python: >=3.11
 Description-Content-Type: text/markdown
 License-File: LICENSE
 Requires-Dist: fastcore>=2.2.2
-Requires-Dist: jupyasyncclient>=0.2.1
+Requires-Dist: jupyasyncclient>=0.2.2
 Requires-Dist: mcpmini>=0.0.1
 Requires-Dist: aidialog>=0.0.7
 Requires-Dist: pillow
@@ -28,7 +28,7 @@ Dynamic: license-file
 
 `clikernel` gives an LLM agent a persistent Python workbench built from two processes. A [jupygate](https://github.com/AnswerDotAI/jupygate) server runs all the time and hosts real Jupyter kernels ([ipymini](https://github.com/AnswerDotAI/ipymini) by default); kernels live there and persist until explicitly stopped. `clikernel` itself starts and stops with each conversation: a small translator the MCP host launches, speaking MCP to the model and the Jupyter kernels API to the gateway. Outputs come back as concise text — a bare `42` for a single result, tagged sections for several, tracebacks ANSI-stripped and capped.
 
-Because kernels outlive conversations, an agent can `connect` back to yesterday’s kernel (or the user’s live solveit kernel) and find its state intact — and because nothing is ever stopped implicitly, the only way a kernel dies is an explicit `stop_kernel`. Creating a kernel runs the user’s `startup.py` and installs their `inspectors.py` cell-checking rules, delivered as source so remote kernels get the same setup as local ones.
+Because kernels outlive conversations, an agent can `connect` back to yesterday’s kernel (or the user’s live solveit kernel) and find its state intact. Kernels created or attached explicitly are never stopped implicitly: only `stop_kernel` ends them. The one exception is the auto kernel: an `execute` with nothing connected creates a kernel scoped to the conversation, stopped again when the conversation ends or the agent connects elsewhere. Creating a kernel runs the user’s `startup.py` and installs their `inspectors.py` cell-checking rules, delivered as source so remote kernels get the same setup as local ones.
 
 ## Install
 
@@ -50,7 +50,7 @@ Register the stdio server with your MCP host, e.g. for Claude Code:
 claude mcp add clikernel -- clikernel-mcp
 ```
 
-The tools mirror jupygate’s kernel API plus one composite: `connect` (create a fresh kernel — running `startup.py` and installing inspectors — or attach to an existing one by id), `execute` (run code, get concise text), `list_kernels`, `stop_kernel`, `restart`, and `interrupt`. Nothing happens until the model calls `connect`, and nothing is ever stopped except by `stop_kernel` — a later conversation reattaches to a kernel by id and continues where the last one stopped. `$CLIKERNEL_HOST` overrides the default gateway (`http://127.0.0.1:8787`).
+The tools mirror jupygate’s kernel API plus one composite: `connect` (create a fresh kernel — running `startup.py` and installing inspectors — or attach to an existing one by id), `execute` (run code, get concise text), `list_kernels`, `stop_kernel`, `restart`, and `interrupt`. An `execute` with no kernel connected auto-creates one, scoped to the conversation: it stops at conversation end, or when `connect` moves elsewhere. Kernels made or attached with an explicit `connect` are stopped only by `stop_kernel` — a later conversation reattaches by id and continues where the last one stopped. `$CLIKERNEL_HOST` overrides the default gateway (`http://127.0.0.1:8787`).
 
 ## Configuration
 

{clikernel-0.2.2 → clikernel-0.2.3}/README.md

@@ -5,7 +5,7 @@
 
 `clikernel` gives an LLM agent a persistent Python workbench built from two processes. A [jupygate](https://github.com/AnswerDotAI/jupygate) server runs all the time and hosts real Jupyter kernels ([ipymini](https://github.com/AnswerDotAI/ipymini) by default); kernels live there and persist until explicitly stopped. `clikernel` itself starts and stops with each conversation: a small translator the MCP host launches, speaking MCP to the model and the Jupyter kernels API to the gateway. Outputs come back as concise text — a bare `42` for a single result, tagged sections for several, tracebacks ANSI-stripped and capped.
 
-Because kernels outlive conversations, an agent can `connect` back to yesterday’s kernel (or the user’s live solveit kernel) and find its state intact — and because nothing is ever stopped implicitly, the only way a kernel dies is an explicit `stop_kernel`. Creating a kernel runs the user’s `startup.py` and installs their `inspectors.py` cell-checking rules, delivered as source so remote kernels get the same setup as local ones.
+Because kernels outlive conversations, an agent can `connect` back to yesterday’s kernel (or the user’s live solveit kernel) and find its state intact. Kernels created or attached explicitly are never stopped implicitly: only `stop_kernel` ends them. The one exception is the auto kernel: an `execute` with nothing connected creates a kernel scoped to the conversation, stopped again when the conversation ends or the agent connects elsewhere. Creating a kernel runs the user’s `startup.py` and installs their `inspectors.py` cell-checking rules, delivered as source so remote kernels get the same setup as local ones.
 
 ## Install
 
@@ -27,7 +27,7 @@ Register the stdio server with your MCP host, e.g. for Claude Code:
 claude mcp add clikernel -- clikernel-mcp
 ```
 
-The tools mirror jupygate’s kernel API plus one composite: `connect` (create a fresh kernel — running `startup.py` and installing inspectors — or attach to an existing one by id), `execute` (run code, get concise text), `list_kernels`, `stop_kernel`, `restart`, and `interrupt`. Nothing happens until the model calls `connect`, and nothing is ever stopped except by `stop_kernel` — a later conversation reattaches to a kernel by id and continues where the last one stopped. `$CLIKERNEL_HOST` overrides the default gateway (`http://127.0.0.1:8787`).
+The tools mirror jupygate’s kernel API plus one composite: `connect` (create a fresh kernel — running `startup.py` and installing inspectors — or attach to an existing one by id), `execute` (run code, get concise text), `list_kernels`, `stop_kernel`, `restart`, and `interrupt`. An `execute` with no kernel connected auto-creates one, scoped to the conversation: it stops at conversation end, or when `connect` moves elsewhere. Kernels made or attached with an explicit `connect` are stopped only by `stop_kernel` — a later conversation reattaches by id and continues where the last one stopped. `$CLIKERNEL_HOST` overrides the default gateway (`http://127.0.0.1:8787`).
 
 ## Configuration
 

{clikernel-0.2.2 → clikernel-0.2.3}/clikernel/__init__.py

@@ -8,4 +8,4 @@ Modules:
 - `clikernel.skill`: Use the persistent `clikernel` MCP session as the default workspace for any task advanced through live Python execution -- stateful inspection, file-editing workflows, debugging, experiments, API probes, data transforms, or notebook-style work. Read this before writing, running, or debugging Python code in a session with `clikernel` connected.
 - `clikernel.stream`: Streaming JSON-lines worker protocol: nbformat-shaped output events, and a supervisor for select-based UIs."""
 
-__version__ = "0.2.2"
+__version__ = "0.2.3"

{clikernel-0.2.2 → clikernel-0.2.3}/clikernel/core.py

@@ -1,13 +1,13 @@
 """Connect to jupygate-hosted kernels and turn execution into concise text
 
-clikernel is the LLM side of a two-process design: jupygate runs all the time and hosts the kernels; clikernel starts and stops with each conversation and holds nothing but a pointer. This module is the whole client: gateway resolution from `gateways.toml`, the concise-text rendering contract (ANSI-stripped, capped tracebacks), delivery of `startup.py` and `inspectors.py` into freshly created kernels, and `Client` — connect (create or attach), execute, interrupt, restart, stop, list. The MCP and CLI frontends are thin faces over `Client`; nothing here creates or kills a kernel except when asked.
+clikernel is the LLM side of a two-process design: jupygate runs all the time and hosts the kernels; clikernel starts and stops with each conversation and holds nothing but a pointer. This module is the whole client: gateway resolution from `gateways.toml`, the concise-text rendering contract (ANSI-stripped, capped tracebacks), delivery of `startup.py` and `inspectors.py` into freshly created kernels, and `Client` — connect (create or attach), execute, interrupt, restart, stop, list. The MCP and CLI frontends are thin faces over `Client`; nothing here creates or kills a kernel except when asked, and the one scoped kill is opt-in: a kernel created with `auto=True` belongs to its client, ended by that client's next `connect` or by the frontend on the way out.
 
 Docs: https://AnswerDotAI.github.io/clikernel/core.html.md"""
 
 # AUTOGENERATED! DO NOT EDIT! File to edit: ../nbs/00_core.ipynb.
 
 # %% auto #0
-__all__ = ['DEFAULT_URL', 'STATE_LOST', 'cfg_dir', 'gateways', 'resolve', 'Client']
+__all__ = ['DEFAULT_URL', 'MAXLEN', 'STATE_LOST', 'cfg_dir', 'gateways', 'resolve', 'Client']
 
 # %% ../nbs/00_core.ipynb #2b3b7f4a
 import os, tomllib
@@ -18,6 +18,7 @@ from jupyasyncclient import JupyAsyncMultiKernelManager, DeadKernelError
 
 # %% ../nbs/00_core.ipynb #596419b8
 DEFAULT_URL = 'http://127.0.0.1:8787'
+MAXLEN = 180 # Most characters shown per displayed line
 
 def cfg_dir():
     "The clikernel config directory"
@@ -94,7 +95,7 @@ STATE_LOST = 'NOTE: the kernel restarted with a fresh interpreter: all session s
 
 class Client:
     "One conversation's connection: a gateway manager, and the current kernel"
-    def __init__(self, cfgdir=None): self.cfgdir,self.mgr,self.kc,self.kid = cfgdir,None,None,None
+    def __init__(self, cfgdir=None): self.cfgdir,self.mgr,self.kc,self.kid,self.auto = cfgdir,None,None,None,False
 
     async def _use(self, mgr, kid):
         "Point at `kid` on `mgr`, dropping any previous ws (never the kernel)"
@@ -106,8 +107,14 @@ class Client:
 
 # %% ../nbs/00_core.ipynb #94497e4a
 @patch
-async def connect(self:Client, host='', kernel=''):
-    "Connect to a gateway (create a kernel, or attach to `kernel` by id prefix); the pointer aims at it afterwards"
+async def connect(self:Client, host='', kernel='', auto=False):
+    "Connect to a gateway (create a kernel, or attach to `kernel` by id prefix); the pointer aims at it afterwards; `auto` marks a created kernel as client-scoped"
+    note = ''
+    if self.auto:   # scoped to this client: any new connect ends it, even one already dead
+        try: await self.stop()
+        except Exception as e:
+            self.kc,self.kid,self.auto = None,None,False
+            note = f'\nnote: stopping the auto kernel failed ({e})'
     url,tok = resolve(host, self.cfgdir)
     mgr = JupyAsyncMultiKernelManager(url, token=tok)
     ks = await mgr.list_kernels()   # verify reachability and auth now, loudly
@@ -115,7 +122,7 @@ async def connect(self:Client, host='', kernel=''):
         kid = first(k['id'] for k in ks if k['id'].startswith(kernel))
         if not kid: raise ValueError(f'no kernel matching {kernel!r} on {url}: {[k["id"][:8] for k in ks]}')
         await self._use(mgr, kid)
-        return f'connected to existing kernel {kid} on {url}'
+        return f'connected to existing kernel {kid} on {url}' + note
     kw = dict(cwd=os.getcwd(), env=dict(os.environ)) if not host else {}   # the default gateway is local by definition: kernels start where, and as, the conversation lives (cwd and environment - so kernel-side tools that key state to the conversation, like llmdojo's doc-state, resolve it correctly)
     kid = await mgr.start_kernel(**kw)
     await self._use(mgr, kid)
@@ -128,7 +135,8 @@ async def connect(self:Client, host='', kernel=''):
             await self.mgr.shutdown_kernel(kid)
             self.kc,self.kid = None,None
             raise RuntimeError(f'inspectors.py failed to load; kernel stopped:\n{res}')
-    return f'created kernel {kid} on {url}' + (f'\n{out}' if out.strip() else '')
+    self.auto = auto
+    return f'created kernel {kid} on {url}' + (f'\n{out}' if out.strip() else '') + note
 
 @patch
 async def execute_outs(self:Client, code):
@@ -141,7 +149,7 @@ async def execute_outs(self:Client, code):
 async def execute(self:Client, code):
     "Run `code` in the current kernel; concise rendered text of its outputs"
     r = await self.execute_outs(code)
-    return r if isinstance(r, str) else render_text(r, tb_maxlen=120)
+    return r if isinstance(r, str) else render_text(r, tb_maxlen=MAXLEN)
 
 # %% ../nbs/00_core.ipynb #1ef42fff
 @patch
@@ -167,7 +175,7 @@ async def stop(self:Client, kernel=''):
     await self.mgr.shutdown_kernel(kid)
     if kid == self.kid:
         await self.kc.aclose()
-        self.kc,self.kid = None,None
+        self.kc,self.kid,self.auto = None,None,False
     return f'stopped kernel {kid}'
 
 @patch

{clikernel-0.2.2 → clikernel-0.2.3}/clikernel/mcp.py

@@ -1,6 +1,6 @@
 """The MCP frontend: `Client` as tools on stdio
 
-The frontend Claude Code launches per conversation: `mk_server` closes the tools over a `Client`, and `main` (the `clikernel-mcp` console script) serves it on stdio via mcpmini. There is no instructions machinery and nothing eager — usage is taught by skill text, the server answers `initialize` instantly, and nothing happens until the model calls `connect`. Tool descriptions carry v1's hard-won wording.
+The frontend Claude Code launches per conversation: `mk_server` closes the tools over a `Client`, and `main` (the `clikernel-mcp` console script) serves it on stdio via mcpmini. There is no instructions machinery and nothing eager — usage is taught by skill text, the server answers `initialize` instantly, and nothing happens until the first tool call. An `execute` with no kernel connected auto-connects first, so `connect` is only needed to attach, to reach another gateway, or to make a kernel that outlives the conversation. Tool descriptions carry v1's hard-won wording.
 
 Docs: https://AnswerDotAI.github.io/clikernel/mcp.html.md"""
 
@@ -17,7 +17,7 @@ from aidialog.dialog import Message
 from aidialog.hist import output_parts, merge_media
 from aidialog.msg_parts import PartType, data_url
 from fastcore.nbio import render_text
-from .core import Client
+from .core import Client, MAXLEN
 from . import __version__
 
 
@@ -31,21 +31,28 @@ def part2block(p):
 # %% ../nbs/01_mcp.ipynb #76e2d782
 def mk_server(c:Client):
     "An `MCPServer` whose tools close over `c`: connect, execute, and the lifecycle verbs"
+    alock = asyncio.Lock()
     async def connect(
         host:str='', # Gateway: empty for the default local jupygate, a `gateways.toml` name, or a URL
         kernel:str='', # Kernel id (or unique prefix) to attach to; empty creates a fresh kernel
     )->str:
-        "Connect to a kernel. With `kernel`: attach to that existing kernel exactly as it is (nothing is run) - this is how a later conversation returns to live state, and how to reach a kernel someone else created. Without: create a fresh kernel, run the user's startup.py in it, and install their inspectors; the reply includes the new kernel's id (reusable in a later `connect`) and the startup output. Kernels persist until explicitly stopped: disconnecting, switching, and conversation end never kill anything."
+        "Connect to a kernel. With `kernel`: attach to that existing kernel exactly as it is (nothing is run) - this is how a later conversation returns to live state, and how to reach a kernel someone else created. Without: create a fresh kernel, run the user's startup.py in it, and install their inspectors; the reply includes the new kernel's id (reusable in a later `connect`) and the startup output. Kernels made or attached this way persist until explicitly stopped: disconnecting, switching, and conversation end never kill them. (Connecting also immediately stops the auto kernel, if `execute` had created one.)"
         return await c.connect(host, kernel)
 
     async def execute(
         code:str, # Python/IPython code to run
     ):
-        "Run `code` in the current kernel, keeping state across calls (imports, variables, monkeypatches, cached objects). Requires a `connect` first. If the reply says the kernel died, `connect` again. Image outputs (plots etc.) come back as image blocks, resized to a token-friendly size, each preceded by its `<media id=...>` tag."
+        "Run `code` in the current kernel, keeping state across calls (imports, variables, monkeypatches, cached objects). With no kernel connected, one is auto-created first (default gateway, startup.py and inspectors run), and its connect banner - kernel id and startup output - is prepended to the reply: read it. An auto-created kernel is scoped to the conversation: it stops when the conversation ends or when `connect` moves elsewhere; use `connect` for a kernel that should outlive the conversation. If the reply says the kernel died, `connect` again. Image outputs (plots etc.) come back as image blocks, resized to a token-friendly size, each preceded by its `<media id=...>` tag."
+        pre = ''
+        async with alock:   # parallel first calls must not each create a kernel
+            if not c.kc: pre = await c.connect(auto=True) + '\n'
         r = await c.execute_outs(code)
-        if isinstance(r, str): return r
-        res = merge_media(render_text(r, tb_maxlen=120), output_parts(Message(msg_type='code', output=r)))
-        return res if isinstance(res, str) else dict(content=[part2block(p) for p in res], isError=False)
+        if isinstance(r, str): return pre + r
+        res = merge_media(render_text(r, tb_maxlen=MAXLEN), output_parts(Message(msg_type='code', output=r)))
+        if isinstance(res, str): return pre + res
+        blocks = [part2block(p) for p in res]
+        if pre: blocks = [dict(type='text', text=pre)] + blocks
+        return dict(content=blocks, isError=False)
 
     async def list_kernels(
         host:str='', # Gateway to list; empty for the current one (or the default if not connected)
@@ -56,7 +63,7 @@ def mk_server(c:Client):
     async def stop_kernel(
         kernel:str='', # Kernel id (or unique prefix); empty stops the current kernel
     )->str:
-        "Stop a kernel for good: its process ends and its state is gone. This is the only way any kernel is ever stopped - do it when the user is done with it, and leave kernels running that the user wants to return to."
+        "Stop a kernel for good: its process ends and its state is gone. Explicitly created or attached kernels are stopped only this way - do it when the user is done with a kernel, and leave kernels running that the user wants to return to. (A kernel auto-created by `execute` also stops itself when the conversation ends or when `connect` moves elsewhere.)"
         return await c.stop(kernel)
 
     async def restart()->str:
@@ -76,6 +83,10 @@ def main():
     async def _main():
         c = Client()
         try: await serve_stdio(mk_server(c))
-        finally: await c.aclose()
+        finally:
+            if c.auto:   # an execute-made kernel is conversation-scoped; the gateway may already be gone
+                try: await c.stop()
+                except Exception as e: print(f'auto kernel stop failed: {e!r}', file=sys.stderr)
+            await c.aclose()
     asyncio.run(_main())
 

{clikernel-0.2.2 → clikernel-0.2.3}/clikernel/skill.py

@@ -2,17 +2,17 @@
 
 # Core idea
 
-clikernel connects this conversation to Jupyter kernels hosted by a jupygate server that runs all the time, independently of any conversation. Kernels persist until explicitly stopped: state kept across the whole conversation -- imports, live objects, monkeypatches, cached results -- and, when wanted, across conversations. Treat it as a notebook-style workbench, not a one-shot script runner.
+clikernel connects this conversation to Jupyter kernels hosted by a jupygate server that runs all the time, independently of any conversation. State lasts the whole conversation -- imports, live objects, monkeypatches, cached results -- and a kernel you `connect` explicitly persists across conversations too. Treat it as a notebook-style workbench, not a one-shot script runner.
 
-Prefer it over one-off Python scripts (`python -c`, shell heredocs) whenever you need to inspect runtime behavior, test an idea, call a Python API, examine package state, run a live probe, or iterate on an implementation detail. Prefer in-kernel tools over shell equivalents when they exist: file search and directory listing go through the `rgapi` pyskill (`rg()`/`fd()`/`ls()`), and GitHub work through the `ghapi` pyskill, when those are installed. Shell commands remain the right tool for local git operations, project test/build commands, and non-Python tools.
+Prefer it over one-off Python scripts (`python -c`, shell heredocs) whenever you need to inspect runtime behavior, test an idea, call a Python API, examine package state, run a live probe, or iterate on an implementation detail. Prefer in-kernel tools over shell equivalents when they exist: file search and directory listing go through the `rgapi` pyskill (`rg()`/`fd()`/`ls()`), and GitHub and local git work through the `ghapi` pyskill, when those are installed. Shell commands remain the right tool for project test/build commands and non-Python tools. Run them through the harness's shell tool, never `subprocess`/`os.system` from the kernel, which would bypass the harness's permission hooks.
 
 # The lifecycle contract
 
-Nothing is implicit. There is no kernel until `connect` is called, and no kernel is ever stopped except by `stop_kernel`. The tools are self-documenting -- read each tool's MCP description -- and the shape of a session is:
+The lifecycle has one implicit convenience and no implicit destruction beyond it. An `execute` with no kernel connected auto-creates one (default gateway, `startup.py` and inspectors as usual), and the connect banner arrives prepended to that first reply. That auto kernel is scoped to the conversation: it stops when the conversation ends, or the moment `connect` moves anywhere else. Kernels you `connect` explicitly -- created bare or attached by id -- are never stopped except by `stop_kernel`. The tools are self-documenting -- read each tool's MCP description -- and the shape of a session is:
 
-- Start of work: `connect` (bare) creates a fresh kernel, runs the user's `startup.py`, installs their inspectors, and replies with the kernel id and the startup output. Read that output: it says what is imported and what to do next.
+- Start of work: just `execute` (the first call auto-connects; read the banner: it says what is imported and what to do next), or a bare `connect` when the kernel should outlive the conversation.
 - Returning to earlier work (the user asks to continue where a previous conversation left off, or to use their solveit kernel): `list_kernels` to see what's running, then `connect` with the kernel id (or unique prefix). Attach runs nothing -- the kernel's live state is the point.
-- End of work: `stop_kernel` if the kernel was for this task only; leave it running if the user wants to return to it, and tell the user its id so they can.
+- End of work: an auto kernel stops itself with the conversation. `stop_kernel` an explicitly created kernel when it was for this task only; leave it running if the user wants to return to it, and tell the user its id so they can.
 
 `restart` gives the current kernel a genuinely fresh interpreter under the same id (redo imports after it); `interrupt` stops a too-long `execute` while keeping state. If a reply says the kernel died, `connect` again. If `connect` fails because the gateway is unreachable, the jupygate server is not running -- report that to the user rather than working around it.
 
@@ -22,13 +22,15 @@ Remote gateways (a jupygate or solveit instance elsewhere) are the same verbs wi
 
 `execute` runs IPython, so magics work as written. The `%nbrun` line magic (registered by aidialog, which the standard startup imports) runs cells from a `.ipynb` file by cell id prefix -- see `doc(dsk)` after startup for its options. It runs *in the kernel*, so its cells share session state and are checked by the session's inspectors.
 
+`%cd` expands `~` and is the idiomatic way to change the kernel's directory: prefer it over `os.chdir`.
+
 # Session setup
 
 `connect` (creating) first runs `~/.config/clikernel/startup.py` (with `__file__` bound, so the file can locate its neighbors), then installs inspectors from `~/.config/clikernel/inspectors.py`. Both travel as source, so remote kernels get the same setup as local ones. Inspectors see each cell before it runs (1-arg: the AST; 2-arg: AST and raw source): a returned string prints as a note ahead of the cell's output, raising `RuleBlock` (provided in the file's namespace) blocks the cell, and inspector bugs warn and fail open. Attached kernels are taken as found: no startup, no inspectors.
 
 # Output shape
 
-Outputs are rendered with `fastcore.nbio.render_text`. A single non-empty output comes back as its preferred text form, e.g. `42`; multiple outputs use readable XML-ish tags (`<stdout>`, `<execute_result>`, ...) with raw, unescaped body text. Exceptions come back as one clean traceback: ANSI-stripped, over-long lines capped at 120 characters with `File `/`Cell ` locations and the exception message always whole. `input()` fails fast in-band (`allow_stdin=False`) rather than hanging. Image outputs (plots etc.) arrive as MCP image blocks, resized to a token-friendly budget, each preceded by a `<media id=...>` text tag naming it; when the image cannot be delivered, a `<media-unavailable>` note appears in the text instead.
+Outputs are rendered with `fastcore.nbio.render_text`. A single non-empty output comes back as its preferred text form, e.g. `42`; multiple outputs use readable XML-ish tags (`<stdout>`, `<execute_result>`, ...) with raw, unescaped body text. Exceptions come back as one clean traceback: ANSI-stripped, over-long lines capped at 180 characters with `File `/`Cell ` locations and the exception message always whole. `input()` fails fast in-band (`allow_stdin=False`) rather than hanging. Image outputs (plots etc.) arrive as MCP image blocks, resized to a token-friendly budget, each preceded by a `<media id=...>` text tag naming it; when the image cannot be delivered, a `<media-unavailable>` note appears in the text instead.
 
 # Interaction rules
 

{clikernel-0.2.2 → clikernel-0.2.3/clikernel.egg-info}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: clikernel
-Version: 0.2.2
+Version: 0.2.3
 Summary: Serve persistent Jupyter kernels to LLMs as concise text, over MCP or a plain stream protocol
 Author: clikernel contributors
 License: Apache-2.0
@@ -12,7 +12,7 @@ Requires-Python: >=3.11
 Description-Content-Type: text/markdown
 License-File: LICENSE
 Requires-Dist: fastcore>=2.2.2
-Requires-Dist: jupyasyncclient>=0.2.1
+Requires-Dist: jupyasyncclient>=0.2.2
 Requires-Dist: mcpmini>=0.0.1
 Requires-Dist: aidialog>=0.0.7
 Requires-Dist: pillow
@@ -28,7 +28,7 @@ Dynamic: license-file
 
 `clikernel` gives an LLM agent a persistent Python workbench built from two processes. A [jupygate](https://github.com/AnswerDotAI/jupygate) server runs all the time and hosts real Jupyter kernels ([ipymini](https://github.com/AnswerDotAI/ipymini) by default); kernels live there and persist until explicitly stopped. `clikernel` itself starts and stops with each conversation: a small translator the MCP host launches, speaking MCP to the model and the Jupyter kernels API to the gateway. Outputs come back as concise text — a bare `42` for a single result, tagged sections for several, tracebacks ANSI-stripped and capped.
 
-Because kernels outlive conversations, an agent can `connect` back to yesterday’s kernel (or the user’s live solveit kernel) and find its state intact — and because nothing is ever stopped implicitly, the only way a kernel dies is an explicit `stop_kernel`. Creating a kernel runs the user’s `startup.py` and installs their `inspectors.py` cell-checking rules, delivered as source so remote kernels get the same setup as local ones.
+Because kernels outlive conversations, an agent can `connect` back to yesterday’s kernel (or the user’s live solveit kernel) and find its state intact. Kernels created or attached explicitly are never stopped implicitly: only `stop_kernel` ends them. The one exception is the auto kernel: an `execute` with nothing connected creates a kernel scoped to the conversation, stopped again when the conversation ends or the agent connects elsewhere. Creating a kernel runs the user’s `startup.py` and installs their `inspectors.py` cell-checking rules, delivered as source so remote kernels get the same setup as local ones.
 
 ## Install
 
@@ -50,7 +50,7 @@ Register the stdio server with your MCP host, e.g. for Claude Code:
 claude mcp add clikernel -- clikernel-mcp
 ```
 
-The tools mirror jupygate’s kernel API plus one composite: `connect` (create a fresh kernel — running `startup.py` and installing inspectors — or attach to an existing one by id), `execute` (run code, get concise text), `list_kernels`, `stop_kernel`, `restart`, and `interrupt`. Nothing happens until the model calls `connect`, and nothing is ever stopped except by `stop_kernel` — a later conversation reattaches to a kernel by id and continues where the last one stopped. `$CLIKERNEL_HOST` overrides the default gateway (`http://127.0.0.1:8787`).
+The tools mirror jupygate’s kernel API plus one composite: `connect` (create a fresh kernel — running `startup.py` and installing inspectors — or attach to an existing one by id), `execute` (run code, get concise text), `list_kernels`, `stop_kernel`, `restart`, and `interrupt`. An `execute` with no kernel connected auto-creates one, scoped to the conversation: it stops at conversation end, or when `connect` moves elsewhere. Kernels made or attached with an explicit `connect` are stopped only by `stop_kernel` — a later conversation reattaches by id and continues where the last one stopped. `$CLIKERNEL_HOST` overrides the default gateway (`http://127.0.0.1:8787`).
 
 ## Configuration
 

{clikernel-0.2.2 → clikernel-0.2.3}/clikernel.egg-info/requires.txt

@@ -1,5 +1,5 @@
 fastcore>=2.2.2
-jupyasyncclient>=0.2.1
+jupyasyncclient>=0.2.2
 mcpmini>=0.0.1
 aidialog>=0.0.7
 pillow

{clikernel-0.2.2 → clikernel-0.2.3}/pyproject.toml

@@ -17,7 +17,7 @@ classifiers = [
 
 dependencies = [
   "fastcore>=2.2.2",
-  "jupyasyncclient>=0.2.1",
+  "jupyasyncclient>=0.2.2",
   "mcpmini>=0.0.1",
   "aidialog>=0.0.7",
   "pillow",