0 added, 1 removed. Audit A to A.
---
name: persistent-python
description: The persistent clikernel Python session — Jeremy's preferred single tool for nearly ALL Python work. TRIGGER — read and bootstrap as step zero of EVERY session where clikernel is available, before the first tool call: even tasks that only read a file or search a directory, plus stateful inspection, editing code or notebooks, debugging, experiments, API probes, data transforms, pyskills discovery, notebook-style work, local tool orchestration. If it could go through Python, it goes here — never python -c, Bash heredocs, or ad hoc scripts.
---
# Persistent Python
ALWAYS use the `clikernel` MCP server for ALL Python work: writing code, editing code or notebooks, running or debugging anything, inspecting objects or packages, probing APIs, and transforming data. It is the workbench for every task in this environment. If the work could go through Python, it goes through clikernel. Do not fall back to `python -c`, shell heredocs, or ad hoc scripts.
The server's `py` tool runs code in one persistent IPython session, so imports, variables, monkeypatches, and cached objects carry across calls. Check the clikernel MCP server instructions already in your context before the first call. The first `py` creates the kernel, and its reply opens with the startup banner: what is imported, and which cells to run next. Follow it. If the banner reports that project imports were skipped, or no banner appears, report that to the user before other work. Then run the guarded import block from `$XDG_CONFIG_HOME/clikernel/startup.py` (default `~/.config/clikernel/startup.py`) as one `py` call. That file is the single source of truth for bootstrap imports; never retype them from memory.
Complete every practice task named in the server instructions (the llmdojo round started by `dojo_start()`) before any other work. This gate applies in every session, including tasks that only read files or search directories.
The server instructions and startup docs cover the tools, notebook magics, output shape, interaction rules, reload gotchas, and pyskills workflow, so this skill does not repeat them. `list_pyskills()` shows the available tooling. Prefer a relevant pyskill over ad hoc code.
## Environment specifics
The following apply specifically to this environment:
- After a kernel restart or compaction, read `doc(f)` again for any tooling function whose docs are no longer in your context.
- Use `exhash` for ALL edits -- code, tests, config, prose, notebook cells -- never the harness's built-in file-edit tools, and read with `lnhashview_*` (not the harness's file reader) the moment an edit is plausible. `aidialog.dlgskill` covers the structural cell/message operations exhash doesn't; `fastcore.tools` file editors are the rare fallback where exhash can't express a text edit.
- Claude Code settings are plain JSON: `~/.claude/settings.json` (user-global), `.claude/settings.json` (project, committed), `.claude/settings.local.json` (project, personal); later files override earlier. Edit them with the normal kernel tooling (`lnhashview_file` + `%%exhash`), merging into existing keys rather than replacing, then verify with a duplicate-key-rejecting parse - `json.loads(s, object_pairs_hook=<raiser>)` - because `json.loads` alone silently keeps the last duplicate while the stricter serde parsers that also consume these files (codex) reject the file outright. Useful facts: a BARE tool name in `permissions.deny` removes that tool from the system prompt entirely, while a scoped rule (`Bash(rm *)`) only blocks matching calls; hooks live under `"hooks"` keyed by event (PreToolUse, SessionStart, UserPromptSubmit, ...); `skillOverrides` hides bundled skills (`"off"`, or `"user-invocable-only"` to keep the slash command usable by the user). Settings load at startup, so changes take effect from the next session.
- Codex settings are TOML: `~/.codex/config.toml` is user-global, while trusted `.codex/config.toml` files apply from the project root down to the current directory, with the closest project file winning. CLI overrides have higher precedence. Hooks can live in `hooks.json` or inline `[hooks]` tables at user and project config layers; matching hooks from every active layer are merged. `PreToolUse` can inspect, deny, or rewrite Bash, `apply_patch`, MCP, and most other local tool calls. `[[skills.config]]` entries enable or disable skills by path, while `mcp_servers.<id>.enabled_tools` and `disabled_tools` control which MCP tools are exposed. Do not disable Bash or `apply_patch` merely because clikernel is preferred; first establish that sessions misuse them. Config changes take effect after restarting Codex.
- - Narration between consecutive tool calls can go in plain text as normal. Mid-run text has been dropped by the interface before (anthropics/claude-code#75900: text emitted immediately before a thinking block), and a sentinel hook still reports it when it happens, so for a long run of clikernel calls a separate `py` call containing only a Python comment is also fine: one or two prose lines starting `#`, saying what the last result showed and what comes next. It runs as a no-op, renders in the transcript, and persists across resume.