In AutoGen, what does JupyterCodeExecutor persist between executions that the command-line executors do not?

middleshould knowfreq 45%

answer

one keeps a process alive
notebook semantics versus fresh subprocess
only files survive in the other
memory grows until you restart
restart() becomes a real recovery tool

basics

~20 s

JupyterCodeExecutor keeps a live kernel, so imports, variables and loaded data survive from one execution to the next. The command-line executors start a fresh process each time, so only files written into work_dir carry over.

solid answer

~50 s

LocalCommandLineCodeExecutor and DockerCommandLineCodeExecutor write each block to a file and invoke an interpreter on it. The process exits when the block finishes, so in-memory state — imports, variables, an open dataframe, a fitted model — is gone; the only continuity is the filesystem under work_dir. JupyterCodeExecutor instead talks to a running Jupyter kernel and sends each block as a cell, so the kernel's namespace persists across calls exactly as a notebook does. That makes iterative work far cheaper: load a 2 GB CSV once and query it in five subsequent turns, instead of reloading it each time. It also captures rich output — a plot becomes a saved image rather than being lost. The costs are a stateful resource you must start, stop and occasionally restart(), memory that only grows, and cross-turn contamination when one execution leaves a broken global behind. There is also a Docker-backed Jupyter executor when you want the persistent kernel inside a container.

`LocalCommandLineCodeExecutor` and `DockerCommandLineCodeExecutor` write each block to a file and invoke an interpreter on it. The process exits when the block finishes, so in-memory state — imports, variables, an open dataframe, a fitted model — is gone; the only continuity is the filesystem under `work_dir`. `JupyterCodeExecutor` instead talks to a running Jupyter kernel and sends each block as a cell, so the kernel's namespace persists across calls exactly as a notebook does. That makes iterative work far cheaper: load a 2 GB CSV once and query it in five subsequent turns, instead of reloading it each time. It also captures rich output — a plot becomes a saved image rather than being lost. The costs are a stateful resource you must start, stop and occasionally `restart()`, memory that only grows, and cross-turn contamination when one execution leaves a broken global behind. There is also a Docker-backed Jupyter executor when you want the persistent kernel inside a container.

code

python · 20 lines

python

import asyncio

from autogen_core import CancellationToken
from autogen_core.code_executor import CodeBlock
from autogen_ext.code_executors.jupyter import JupyterCodeExecutor


async def main() -> None:
    async with JupyterCodeExecutor() as executor:
        token = CancellationToken()
        await executor.execute_code_blocks(
            [CodeBlock(code="total = 41", language="python")], token
        )
        result = await executor.execute_code_blocks(
            [CodeBlock(code="print(total + 1)", language="python")], token
        )
        print(result.exit_code, result.output)


asyncio.run(main())

go deeper

for a junior

Know that the command-line executors start a fresh process for every code block, so only files survive, while a Jupyter-backed executor keeps a kernel alive and variables stay defined.

for a middle

Explain the mechanism on both sides — file-plus-interpreter per block versus cells submitted to a live kernel — and why the kernel makes iterative data work cheaper in tokens and latency.

for a senior

Bring the operational consequences: kernel memory only grows, restart() is your recovery path for a poisoned namespace, and results that depend on hidden session state are not reproducible from the transcript.

for a principal

Own the policy question — when a session's state is an asset versus a liability, how you bound kernel lifetime per task or per tenant, and how the state choice interacts with the isolation choice when you need both.

Two execution models

AutoGen's executors split along a line that has nothing to do with security and everything to do with state.

Process-per-execution. The command-line executors — local and Docker — take each extracted code block, write it to a file in work_dir, and run the appropriate interpreter on that file. The process starts, runs, prints, exits. Whatever it held in memory dies with it. Anything the block wrote to disk stays, because work_dir outlives the process (and, in the Docker case, is bind-mounted so it outlives the container too).

Kernel-backed. JupyterCodeExecutor connects to a Jupyter kernel and submits each block as a cell. The kernel is a long-lived process with a namespace, so import pandas as pd in one execution is still in effect three executions later, and df defined in the second is still bound in the fifth. This is precisely notebook semantics, with all the ergonomics and all the footguns.

Why the difference matters to an agent loop

Agents are iterative by construction: generate, run, read the error, generate again. Under process-per-execution, every iteration pays full setup cost. If the task is "analyse this dataset", the model must either reload the data in every single block — expensive, and the model frequently forgets — or write intermediate results to disk and reload them, which it must be prompted to do. In practice, agents against command-line executors produce long, repetitive scripts, because the only safe assumption is that nothing survives.

Under a kernel, the model can behave the way a data scientist does: one cell to load, one to inspect, one to plot. Token usage drops because each block is small; latency drops because setup happens once. For exploratory data work this is the difference between a usable agent and an infuriating one.

What the kernel costs

First, it is a resource with a lifecycle. Like the Docker executor, you start it and stop it (the async with form does both), and the executor protocol's restart() exists precisely for the moment the namespace is poisoned — a monkey-patched builtin, a global that a failed block left half-assigned, a module imported from a directory that has since changed. Under process-per-execution restart() is nearly meaningless; under a kernel it is your recovery tool.

Second, memory only grows. Nothing reclaims that 2 GB dataframe until the kernel dies. A long-running agent session against a kernel is a memory-leak shape, and the bound has to come from your session policy — restart the kernel between tasks or between users — not from the executor.

Third, state is contamination as well as convenience. A bug that only reproduces because of something an earlier execution left behind is not reproducible from the transcript alone, which makes debugging an agent run genuinely harder. When someone reports "it worked in the session but the generated script fails standalone", the kernel is usually why.

Fourth, isolation. The plain JupyterCodeExecutor runs its kernel locally, so it carries the same trust profile as the local command-line executor: your filesystem, your environment, your network. When you need persistent state and isolation, use the Docker-backed Jupyter executor, which runs the kernel inside a container.

Rich output

A kernel returns display data, not just stdout. That means a matplotlib figure can be captured as an image file (the executor writes such outputs into its configured output directory) instead of vanishing the way it does when a subprocess draws to a display that does not exist. For agents whose deliverable is a chart, this is the deciding feature.

Choosing

Use the command-line executors for one-shot script generation, for CI-style tasks, and whenever you want each execution to be independently reproducible. Use a Jupyter executor for iterative analysis, expensive setup, or plot production — and pair it with an explicit restart policy so a session's memory and its accumulated weirdness both have a bound. In either case the timeout argument still governs a single execution, not the session.

## Two execution models AutoGen's executors split along a line that has nothing to do with security and everything to do with state. **Process-per-execution.** The command-line executors — local and Docker — take each extracted code block, write it to a file in `work_dir`, and run the appropriate interpreter on that file. The process starts, runs, prints, exits. Whatever it held in memory dies with it. Anything the block wrote to disk stays, because `work_dir` outlives the process (and, in the Docker case, is bind-mounted so it outlives the container too). **Kernel-backed.** `JupyterCodeExecutor` connects to a Jupyter kernel and submits each block as a cell. The kernel is a long-lived process with a namespace, so `import pandas as pd` in one execution is still in effect three executions later, and `df` defined in the second is still bound in the fifth. This is precisely notebook semantics, with all the ergonomics and all the footguns. ## Why the difference matters to an agent loop Agents are iterative by construction: generate, run, read the error, generate again. Under process-per-execution, every iteration pays full setup cost. If the task is "analyse this dataset", the model must either reload the data in every single block — expensive, and the model frequently forgets — or write intermediate results to disk and reload them, which it must be prompted to do. In practice, agents against command-line executors produce long, repetitive scripts, because the only safe assumption is that nothing survives. Under a kernel, the model can behave the way a data scientist does: one cell to load, one to inspect, one to plot. Token usage drops because each block is small; latency drops because setup happens once. For exploratory data work this is the difference between a usable agent and an infuriating one. ## What the kernel costs First, it is a resource with a lifecycle. Like the Docker executor, you start it and stop it (the `async with` form does both), and the executor protocol's `restart()` exists precisely for the moment the namespace is poisoned — a monkey-patched builtin, a global that a failed block left half-assigned, a module imported from a directory that has since changed. Under process-per-execution `restart()` is nearly meaningless; under a kernel it is your recovery tool. Second, memory only grows. Nothing reclaims that 2 GB dataframe until the kernel dies. A long-running agent session against a kernel is a memory-leak shape, and the bound has to come from your session policy — restart the kernel between tasks or between users — not from the executor. Third, state is contamination as well as convenience. A bug that only reproduces because of something an earlier execution left behind is not reproducible from the transcript alone, which makes debugging an agent run genuinely harder. When someone reports "it worked in the session but the generated script fails standalone", the kernel is usually why. Fourth, isolation. The plain `JupyterCodeExecutor` runs its kernel locally, so it carries the same trust profile as the local command-line executor: your filesystem, your environment, your network. When you need persistent state *and* isolation, use the Docker-backed Jupyter executor, which runs the kernel inside a container. ## Rich output A kernel returns display data, not just stdout. That means a matplotlib figure can be captured as an image file (the executor writes such outputs into its configured output directory) instead of vanishing the way it does when a subprocess draws to a display that does not exist. For agents whose deliverable is a chart, this is the deciding feature. ## Choosing Use the command-line executors for one-shot script generation, for CI-style tasks, and whenever you want each execution to be independently reproducible. Use a Jupyter executor for iterative analysis, expensive setup, or plot production — and pair it with an explicit restart policy so a session's memory and its accumulated weirdness both have a bound. In either case the `timeout` argument still governs a single execution, not the session.

When would you deliberately choose the process-per-execution model even though it is slower?
When each execution must be independently reproducible: CI jobs, generated scripts you intend to ship, and anything where a result that only works because of leftover session state would be a lie. Fresh-process execution guarantees the code in the transcript is the code that ran, with no hidden preconditions. It also caps memory naturally, since every process exits.
What does restart() do differently for a kernel-backed executor?
For the command-line executors it is close to a no-op, because there is no live state to clear. For a kernel-backed executor it tears down and recreates the kernel, discarding the namespace — the recovery path when an execution has poisoned globals, monkey-patched something, or ballooned memory. Treat it as a session-boundary operation: restart between tasks or between users rather than hoping a long session stays clean.
How do you get persistent state and container isolation at the same time?
Use the Docker-backed Jupyter executor rather than the plain one: the kernel runs inside a container, so the namespace persists across executions while the filesystem and process view belong to the container, not the host. The plain JupyterCodeExecutor runs its kernel locally and therefore carries the same trust profile as the local command-line executor — no isolation at all.

The command-line executors are like running a script from a terminal each time; the Jupyter executor is like keeping a notebook open with all your cells already evaluated.

saying these in an interview costs you the question

Assuming variables persist across blocks with the command-line executors
Thinking work_dir preserves in-memory state, not just files
Treating the local Jupyter executor as sandboxed
Never restarting a kernel during a long agent session
Believing timeout bounds the session rather than one execution

In AutoGen, what does JupyterCodeExecutor persist between executions that the command-line executors do not?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~3 min

Two execution models

Why the difference matters to an agent loop

What the kernel costs

Rich output

Choosing

▾common follow-ups3 questions

▾analogy~10 s

▾red flags5 flags

§ context

▾related questions3 questions

▾related topics2 topics

Two execution models

Why the difference matters to an agent loop

What the kernel costs

Rich output

Choosing

answer

go deeper

context