clikernel 0.2.3__tar.gz → 0.2.4__tar.gz

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

@@ -2,6 +2,13 @@
 
 <!-- do not remove -->
 
+## 0.2.4
+
+### New Features
+
+- Swap jupygate for rustygate; add optional verify flag for self-signed TLS gateways ([#36](https://github.com/AnswerDotAI/clikernel/issues/36))
+
+
 ## 0.2.3
 
 ### New Features

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

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: clikernel
-Version: 0.2.3
+Version: 0.2.4
 Summary: Serve persistent Jupyter kernels to LLMs as concise text, over MCP or a plain stream protocol
 Author: clikernel contributors
 License: Apache-2.0
@@ -18,7 +18,7 @@ Requires-Dist: aidialog>=0.0.7
 Requires-Dist: pillow
 Provides-Extra: dev
 Requires-Dist: fastship; extra == "dev"
-Requires-Dist: jupygate>=0.0.1; extra == "dev"
+Requires-Dist: rustygate>=0.1.1; extra == "dev"
 Dynamic: license-file
 
 # clikernel
@@ -26,7 +26,7 @@ Dynamic: license-file
 
 <!-- WARNING: THIS FILE WAS AUTOGENERATED! DO NOT EDIT! -->
 
-`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.
+`clikernel` gives an LLM agent a persistent Python workbench built from two processes. A gateway ([rustygate](https://github.com/AnswerDotAI/rustygate)) 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. 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.
 
@@ -36,10 +36,10 @@ Because kernels outlive conversations, an agent can `connect` back to yesterday
 pip install clikernel
 ```
 
-Plus the resident side: [jupygate](https://github.com/AnswerDotAI/jupygate) and a kernel ([ipymini](https://github.com/AnswerDotAI/ipymini) by default). Start the gateway (and keep it running, e.g. via launchd/systemd):
+Plus the resident side: [rustygate](https://github.com/AnswerDotAI/rustygate) and a kernel ([ipymini](https://github.com/AnswerDotAI/ipymini) by default). Start the gateway (and keep it running, e.g. via launchd/systemd):
 
 ``` sh
-jupygate --port 8787
+rustygate --port 8787
 ```
 
 ## Use with an MCP host
@@ -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`. 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`).
+The tools mirror the gateway’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
 
@@ -64,6 +64,7 @@ Three optional files in `$XDG_CONFIG_HOME/clikernel/` (usually `~/.config/cliker
 [gateways.solveit]
 url = "https://solveit.example.com/gate"
 token_env = "SOLVEIT_TOKEN"
+verify = false   # optional: accept a self-signed certificate
 ```
 
 ## The stream protocol

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

@@ -3,7 +3,7 @@
 
 <!-- WARNING: THIS FILE WAS AUTOGENERATED! DO NOT EDIT! -->
 
-`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.
+`clikernel` gives an LLM agent a persistent Python workbench built from two processes. A gateway ([rustygate](https://github.com/AnswerDotAI/rustygate)) 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. 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.
 
@@ -13,10 +13,10 @@ Because kernels outlive conversations, an agent can `connect` back to yesterday
 pip install clikernel
 ```
 
-Plus the resident side: [jupygate](https://github.com/AnswerDotAI/jupygate) and a kernel ([ipymini](https://github.com/AnswerDotAI/ipymini) by default). Start the gateway (and keep it running, e.g. via launchd/systemd):
+Plus the resident side: [rustygate](https://github.com/AnswerDotAI/rustygate) and a kernel ([ipymini](https://github.com/AnswerDotAI/ipymini) by default). Start the gateway (and keep it running, e.g. via launchd/systemd):
 
 ``` sh
-jupygate --port 8787
+rustygate --port 8787
 ```
 
 ## Use with an MCP host
@@ -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`. 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`).
+The tools mirror the gateway’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
 
@@ -41,6 +41,7 @@ Three optional files in `$XDG_CONFIG_HOME/clikernel/` (usually `~/.config/cliker
 [gateways.solveit]
 url = "https://solveit.example.com/gate"
 token_env = "SOLVEIT_TOKEN"
+verify = false   # optional: accept a self-signed certificate
 ```
 
 ## The stream protocol

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

@@ -3,9 +3,9 @@
 Modules:
 
 - `clikernel.cli`: The stream-protocol frontend: the service on stdin/stdout for token-reading clients
-- `clikernel.core`: Connect to jupygate-hosted kernels and turn execution into concise text
+- `clikernel.core`: Connect to gateway-hosted kernels and turn execution into concise text
 - `clikernel.mcp`: The MCP frontend: `Client` as tools on stdio
 - `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.3"
+__version__ = "0.2.4"

{clikernel-0.2.3 → clikernel-0.2.4}/clikernel/cli.py

@@ -1,6 +1,6 @@
 """The stream-protocol frontend: the service on stdin/stdout for token-reading clients
 
-The `clikernel` command: the delimiter-framed stdin/stdout protocol v1 established (documented in the README, rationale unchanged — a client that reads stdout as tokens wants no echo, a cheap ack byte, and a per-process random delimiter to read until). The protocol machinery ports from v1 verbatim; underneath, the process is now a thin client of a jupygate kernel. Run bare it creates a kernel and stops it again on exit — whoever ran the command made that decision by running it — while `--kernel` attaches to an existing kernel and leaves it exactly as found. Ctrl-C during a long cell translates into a kernel interrupt, jupyter-console style, instead of killing the process.
+The `clikernel` command: the delimiter-framed stdin/stdout protocol v1 established (documented in the README, rationale unchanged — a client that reads stdout as tokens wants no echo, a cheap ack byte, and a per-process random delimiter to read until). The protocol machinery ports from v1 verbatim; underneath, the process is now a thin client of a gateway kernel. Run bare it creates a kernel and stops it again on exit — whoever ran the command made that decision by running it — while `--kernel` attaches to an existing kernel and leaves it exactly as found. Ctrl-C during a long cell translates into a kernel interrupt, jupyter-console style, instead of killing the process.
 
 Docs: https://AnswerDotAI.github.io/clikernel/cli.html.md"""
 
@@ -120,10 +120,10 @@ _EXITS = ('exit', 'exit()', 'quit', 'quit()')
 
 @call_parse
 def main(
-    host:str='',    # Gateway: empty for the default local jupygate, a `gateways.toml` name, or a URL
+    host:str='',    # Gateway: empty for the local default, a `gateways.toml` name, or a URL
     kernel:str='',  # Kernel id (or unique prefix) to attach to; empty creates a kernel, stopped again on exit
 ):
-    "The `clikernel` console script: the stream protocol over one jupygate kernel"
+    "The `clikernel` console script: the stream protocol over one gateway kernel"
     signal.signal(signal.SIGINT, signal.default_int_handler)
     print("please wait, loading...", flush=True)
     loop = asyncio.new_event_loop()

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

@@ -1,6 +1,6 @@
-"""Connect to jupygate-hosted kernels and turn execution into concise text
+"""Connect to gateway-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, 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.
+clikernel is the LLM side of a two-process design: a gateway ([rustygate](https://github.com/AnswerDotAI/rustygate)) 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"""
 
@@ -25,17 +25,17 @@ def cfg_dir():
     return xdg_config_home()/'clikernel'
 
 def gateways(cfgdir=None):
-    "Named gateways from `gateways.toml`: `{name: {url, token | token_env}}`"
+    "Named gateways from `gateways.toml`: `{name: {url, token | token_env, verify}}`"
     p = (Path(cfgdir) if cfgdir else cfg_dir())/'gateways.toml'
     return tomllib.loads(p.read_text()).get('gateways', {}) if p.exists() else {}
 
 def resolve(host='', cfgdir=None):
-    "`(url, token)` for `host`: empty = the default local gateway, a URL = itself, else a `gateways.toml` name"
-    if not host: return os.environ.get('CLIKERNEL_HOST', DEFAULT_URL), os.environ.get('CLIKERNEL_TOKEN')
-    if '://' in host: return host, os.environ.get('CLIKERNEL_TOKEN')
+    "`(url, token, verify)` for `host`: empty = the default local gateway, a URL = itself, else a `gateways.toml` name"
+    if not host: return os.environ.get('CLIKERNEL_HOST', DEFAULT_URL), os.environ.get('CLIKERNEL_TOKEN'), True
+    if '://' in host: return host, os.environ.get('CLIKERNEL_TOKEN'), True
     g = gateways(cfgdir).get(host)
     if g is None: raise ValueError(f"unknown gateway {host!r}: not a URL, and not in {cfg_dir()/'gateways.toml'}")
-    return g['url'], g.get('token') or os.environ.get(g.get('token_env','')) or None
+    return g['url'], g.get('token') or os.environ.get(g.get('token_env','')) or None, g.get('verify', True)
 
 
 # %% ../nbs/00_core.ipynb #0d846754
@@ -115,8 +115,8 @@ async def connect(self:Client, host='', kernel='', auto=False):
         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)
+    url,tok,ver = resolve(host, self.cfgdir)
+    mgr = JupyAsyncMultiKernelManager(url, token=tok, verify=ver)
     ks = await mgr.list_kernels()   # verify reachability and auth now, loudly
     if kernel:
         kid = first(k['id'] for k in ks if k['id'].startswith(kernel))
@@ -156,8 +156,8 @@ async def execute(self:Client, code):
 async def list_kernels(self:Client, host=''):
     "One line per kernel on the gateway (the current one if `host` is empty and connected)"
     if host or self.mgr is None:
-        url,tok = resolve(host, self.cfgdir)
-        mgr = JupyAsyncMultiKernelManager(url, token=tok)
+        url,tok,ver = resolve(host, self.cfgdir)
+        mgr = JupyAsyncMultiKernelManager(url, token=tok, verify=ver)
         ks = await mgr.list_kernels()
         await mgr.aclose()
     else: ks = await self.mgr.list_kernels()

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

@@ -33,7 +33,7 @@ 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
+        host:str='', # Gateway: empty for the local default, 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 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.)"

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

@@ -2,7 +2,7 @@
 
 # Core idea
 
-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.
+clikernel connects this conversation to Jupyter kernels hosted by a gateway server (rustygate) 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 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.
 
@@ -14,9 +14,9 @@ The lifecycle has one implicit convenience and no implicit destruction beyond it
 - 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: 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.
+`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 gateway server is not running -- report that to the user rather than working around it.
 
-Remote gateways (a jupygate or solveit instance elsewhere) are the same verbs with a `host`: a name from `~/.config/clikernel/gateways.toml` (`[gateways.<name>]` tables with `url` and `token` or `token_env`) or a URL. Tokens live in the config file, never in tool arguments.
+Remote gateways (a rustygate or solveit instance elsewhere) are the same verbs with a `host`: a name from `~/.config/clikernel/gateways.toml` (`[gateways.<name>]` tables with `url`, `token` or `token_env`, and optional `verify = false` for self-signed TLS) or a URL. Tokens live in the config file, never in tool arguments.
 
 # Notebook magics
 

{clikernel-0.2.3 → clikernel-0.2.4}/clikernel/stream.py

@@ -7,7 +7,7 @@ line in (`{"op":"exec","id":n,"code":...}`, `{"op":"complete","id":n,"code":...,
 (stream/display_data/execute_result/error) arrive as `out` events with the
 nbformat dict intact (mime bundles included), then a `done` event. Interrupt is
 not on the wire: the supervisor sends SIGINT to the worker process, which the
-worker maps to a kernel interrupt. The worker connects to jupygate (URL as
+worker maps to a kernel interrupt. The worker connects to a gateway (URL as
 argv[0], default local; a kernel id as argv[1] attaches instead of creating),
 so the compact protocol exercises the full real stack -- which is its point:
 a self-contained test client, and a reminder to keep the layers flexible.

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

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: clikernel
-Version: 0.2.3
+Version: 0.2.4
 Summary: Serve persistent Jupyter kernels to LLMs as concise text, over MCP or a plain stream protocol
 Author: clikernel contributors
 License: Apache-2.0
@@ -18,7 +18,7 @@ Requires-Dist: aidialog>=0.0.7
 Requires-Dist: pillow
 Provides-Extra: dev
 Requires-Dist: fastship; extra == "dev"
-Requires-Dist: jupygate>=0.0.1; extra == "dev"
+Requires-Dist: rustygate>=0.1.1; extra == "dev"
 Dynamic: license-file
 
 # clikernel
@@ -26,7 +26,7 @@ Dynamic: license-file
 
 <!-- WARNING: THIS FILE WAS AUTOGENERATED! DO NOT EDIT! -->
 
-`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.
+`clikernel` gives an LLM agent a persistent Python workbench built from two processes. A gateway ([rustygate](https://github.com/AnswerDotAI/rustygate)) 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. 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.
 
@@ -36,10 +36,10 @@ Because kernels outlive conversations, an agent can `connect` back to yesterday
 pip install clikernel
 ```
 
-Plus the resident side: [jupygate](https://github.com/AnswerDotAI/jupygate) and a kernel ([ipymini](https://github.com/AnswerDotAI/ipymini) by default). Start the gateway (and keep it running, e.g. via launchd/systemd):
+Plus the resident side: [rustygate](https://github.com/AnswerDotAI/rustygate) and a kernel ([ipymini](https://github.com/AnswerDotAI/ipymini) by default). Start the gateway (and keep it running, e.g. via launchd/systemd):
 
 ``` sh
-jupygate --port 8787
+rustygate --port 8787
 ```
 
 ## Use with an MCP host
@@ -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`. 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`).
+The tools mirror the gateway’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
 
@@ -64,6 +64,7 @@ Three optional files in `$XDG_CONFIG_HOME/clikernel/` (usually `~/.config/cliker
 [gateways.solveit]
 url = "https://solveit.example.com/gate"
 token_env = "SOLVEIT_TOKEN"
+verify = false   # optional: accept a self-signed certificate
 ```
 
 ## The stream protocol

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

@@ -6,4 +6,4 @@ pillow
 
 [dev]
 fastship
-jupygate>=0.0.1
+rustygate>=0.1.1

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

@@ -26,7 +26,7 @@ dependencies = [
 [project.optional-dependencies]
 dev = [
   "fastship",
-  "jupygate>=0.0.1",
+  "rustygate>=0.1.1",
 ]
 
 

{clikernel-0.2.3 → clikernel-0.2.4}/tests/test_stream.py

@@ -1,14 +1,14 @@
-"The stream protocol round trip: a real worker subprocess against an in-thread jupygate."
+"The stream protocol round trip: a real worker subprocess against a spawned rustygate."
 import select, sys, time
 import pytest
 
 
 @pytest.fixture(scope="module")
 def gateway():
-    from jupygate.core import create_app, serve
-    server = serve(create_app(), port=0, in_thread=True)
-    yield server.url
-    server.should_exit = True
+    from rustygate.tools import start_gateway
+    g = start_gateway()
+    yield g.url
+    g.stop()
 
 
 def _drain_until(w, pred, timeout=30):