# pipeio_nb_exec: add kernel/env option and fix papermill resolution¶

Problem¶

Goal¶

(promoted from note)

Context¶

(see source note)

Prompt¶

Fix the issue described in /storage2/arash/projects/projio/docs/log/issue/issue-arash-20260407-033705-872924.md. Read it first, then implement the proposed fix.

Acceptance Criteria¶

[ ]

Result¶

Completed in 201.5s (1 steps, model: opus)

Session: 56ce1f27-90fb-4dbc-9d28-6b92038f1b77 Result note: /storage2/arash/worklog/workflow/captures/20260407-034115-96ca4b/note.md

Output¶

Done. Here's a summary of the three changes:

**1. `packages/pipeio/src/pipeio/mcp.py`** — Added `_has_papermill()` helper and changed `mcp_nb_exec` to use `sys.executable` (the MCP server's own Python) for running papermill instead of `python_bin`. Falls back to `python_bin` if the server env lacks papermill. Returns a clear error message if neither env has it.

**2. `src/projio/mcp/pipeio.py`** — Added optional `env` parameter to `pipeio_nb_exec()`. When set, wraps the conda env as the `python_bin` for jupytext sync. Papermill runner resolution is now handled independently inside `mcp_nb_exec`.

**3. `src/projio/mcp/server.py`** — Exposed the new `env` parameter in the MCP tool registration with updated docstring.

The key insight: papermill (the runner) and the notebook kernel (the executor) are independent. Papermill just needs to be importable — it doesn't need to be in the same env that runs the notebook cells. The `-k` flag already handles kernel selection.

## Next Steps

1. Run `make test` in both `packages/pipeio` and the projio root to verify nothing is broken by the changes.
2. Test `pipeio_nb_exec` end-to-end in pixecog (e.g., `pipeio_nb_exec(flow="preprocess_ieeg", name="ttl_removal_demo")`) to confirm papermill resolves correctly from the MCP server env.
3. Update the CLAUDE.md tool routing table to document the new `env` parameter for `pipeio_nb_exec`.