- start_kernel() now accepts injection_code and bridge_socket_path
- Bridge Unix domain socket mounted as volume in container
- Injection code executed once on kernel startup (silent, no history)
- New _execute_injection_code() helper method with error handling
- Parameters passed through SessionManager.create_session()
- Parameters passed through JupyterBackend.execute()
- Updated JUPYTER_IMPLEMENTATION_STATUS.md
This mirrors the MCP injection pattern from the simple executor,
allowing MCP tools to be available in Jupyter sessions.
- Comprehensive status of real Jupyter backend implementation
- Architecture decisions documented (1:1 mapping)
- Completed features and remaining TODOs
- Test status and known issues
- Next steps prioritized
- Architecture diagrams and communication flow
- Replaced mock exec() implementation with real Jupyter protocol
- Uses jupyter-client (host) to connect to ipykernel (container) via ZMQ
- 1:1 mapping: one container per session, one kernel per container
- Proper Jupyter message protocol for code execution
- Kernel lifecycle management (start, execute, shutdown, restart)
- Namespace inspection via introspection code
- Idle kernel cleanup
- Connection file management
- Backed up old implementation as kernel_old.py
TODO:
- Container image needs ipykernel installed
- Need to implement proper port mapping for ZMQ
- Need to mount connection file into container
- Add better kernel readiness check
- Implement restart_kernel properly with KernelManager
- Write tests
