`langgraph dev` Ignores Checkpointer Configuration, Forcing In-Memory Storage and Preventing State Persistence**

[Lambdua]

Checked other resources

• This is a bug, not a usage question. For questions, please use the LangChain Forum (https://forum.langchain.com/).
• I added a clear and detailed title that summarizes the issue.
• I read what a minimal reproducible example is (https://stackoverflow.com/help/minimal-reproducible-example).
• I included a self-contained, minimal example that demonstrates the issue INCLUDING all the relevant imports. The code run AS IS to reproduce the issue.

Example Code

### **Steps to Reproduce**

1.  **Create a `checkpoint_config.py` file to configure an SQLite checkpointer:**

    
    # checkpoint_config.py
    import aiosqlite
    from langgraph.checkpoint.sqlite.aio import AsyncSqliteSaver

    async def get_sqlite_saver():
        # Ensure the database connection is awaitable
        conn = await aiosqlite.connect("checkpoint.db")
        return AsyncSqliteSaver(conn=conn)
    

2.  **Create a `my_graph.py` file defining a simple graph and configuring it with the SQLite checkpointer:**

    
    # my_graph.py
    from typing import TypedDict
    from langgraph.graph import StateGraph
    from checkpoint_config import get_sqlite_saver

    class State(TypedDict):
        value: int

    def step(state: State):
        print(f"Current value: {state['value']}")
        return {"value": state["value"] + 1}

    async def get_graph():
        builder = StateGraph(State)
        builder.add_node("step", step)
        builder.set_entry_point("step")
        builder.add_edge("step", "step")
        
        # Configure the persistent SQLite checkpointer
        checkpointer = await get_sqlite_saver()
        
        print(f"Graph compiled with checkpointer: {checkpointer}")
        graph = builder.compile(checkpointer=checkpointer)
        return graph
    

3.  **Create a `langgraph.json` file pointing to the graph:**

    
    {
      "graphs": {
        "my_agent": "./my_graph.py:get_graph"
      }
    }
    

4.  **Start the service using `langgraph dev`:**

    
    langgraph dev --port 8088
    

5.  **Interact with the service to create some state changes.** For instance, call `ainvoke` several times via the LangGraph Studio or `curl`.

6.  **Restart the `langgraph dev` service.**

Error Message and Stack Trace (if applicable)

### **Expected Behavior**

After restarting the service, the previous conversation state should be fully preserved and loaded, as the checkpointer is configured to use `checkpoint.db`. The `checkpoint.db` file should contain data records.

### **Actual Behavior**

After restarting, all conversation state is lost. Although the `checkpoint.db` file is created, it remains empty. The startup logs from `langgraph dev` clearly indicate that it is using an in-memory runtime:
`[info] Using langgraph_runtime_inmem`
`[info] Starting In-Memory runtime ...`

Description

Problem Description

When using the langgraph dev command for development, we've observed that it ignores any persistent checkpointer (e.g., AsyncSqliteSaver) configured in the code for a graph. Instead, it forcibly uses a temporary in-memory runtime (langgraph_runtime_inmem). This results in the loss of all conversation state upon server restart, which significantly complicates the development and debugging of state-dependent agents.

We expect langgraph dev to either respect the checkpointer configured in the code, similar to when running a script directly, or at least provide a command-line option to enable persistence.

Expected Behavior

After restarting the service, the previous conversation state should be fully preserved and loaded, as the checkpointer is configured to use checkpoint.db. The checkpoint.db file should contain data records.

Actual Behavior

After restarting, all conversation state is lost. Although the checkpoint.db file is created, it remains empty. The startup logs from langgraph dev clearly indicate that it is using an in-memory runtime:
[info] Using langgraph_runtime_inmem
[info] Starting In-Memory runtime ...

This demonstrates that the builder.compile(checkpointer=checkpointer) configuration in the code is completely ignored by langgraph dev.

Additional Context

We have carefully checked our local environment configuration and reviewed the official LangGraph documentation but have been unable to find any instructions on how to enable persistent storage for langgraph dev. We also noticed that even when no checkpointer is provided in the code, langgraph dev does not use the .langgraph_api directory for state persistence as one might expect; the files in that directory are not updated as the conversation progresses. This further reinforces our conclusion that langgraph dev may currently be hardcoded to run in-memory, bypassing all persistence mechanisms.

While we understand that langgraph dev is intended as a development tool, this behavior makes it very difficult to develop complex conversational agents that rely on persistent state. Every code change that triggers a hot reload forces us to recreate the conversation state from scratch, which severely impacts development efficiency.

If this is indeed the intended behavior of langgraph dev, we would appreciate it if this were clarified in the official documentation. If it is a configurable issue, we would be grateful for guidance on how to resolve it. Thank you!

System Info

Environment Information

• LangGraph Version: 0.6.1
• Python Version: 3.12
• Operating System: Windows

langgraph dev --port 8088 --no-browser

[raydrak64]

Having the same experience (Windows 11 and Ubuntu 24.04, Python 3.12 and 3.13 on both OS's). Happy to have found this as I was thinking I was going crazy.

Been working on a project for over a year using the prebuilt agent. Putting in a sqlsaver, sqlite checkpoint file was one of the first things done. Been working just fine. Until recently, I noticed that the database file size, though growing, was a lot smaller than in the past. After taking a look at the file, I see the thread_id, checkpoint_id's, metadata, etc are all there.... However, the conversation state was no longer being saved in the metadata. If you remove the file, it does get created and again all the fields are there. Just nothing about the state is saved.

So, reverted the code a few versions back along with the Python environment and it works as I remember it. Next test, reverting the code but not the environment, using the latest langgraph/langchain modules. It stopped working.

I thought maybe the way you implement checkpoints has changed. It's clearly connecting and accessing the sqlite database as it correctly writes new entries for each in/output. It just fails to save the state any longer.

[beepsoft]

Yes, a custom checkpointer should definitely be allowed. It is very frustrating to loose older threads while developing.

[beepsoft]

In the meantime I am experimenting with https://github.com/ibbybuilds/aegra, which is an open source implementation of the LangGraph platform. Not yet a drop-in replacement and not as easy to use as langgraph dev, but it already stores checkpoint data in postgres, so it is better devex when the server reloads after editing files.

[Lambdua]

In the meantime I am experimenting with https://github.com/ibbybuilds/aegra, which is an open source implementation of the LangGraph platform. Not yet a drop-in replacement and not as easy to use as langgraph dev, but it already stores checkpoint data in postgres, so it is better devex when the server reloads after editing files.

thanks; i will try

[casparb]

Hi Lambdua (@Lambdua) Balázs E. Pataki (@beepsoft) - langgraph dev is strictly for development and so it is by design that langgraph api will use an in-memory checkpointer. We have no plans to support alternative checkpointers here. If you want persistent storage you can deploy on LangGraph Platform, where you have a few deployment options: see the docs.

[beepsoft]

Caspar Broekhuizen (@casparb) But exactly the point of having some form of persistence is that during development, when we fix the code and the process restarts we would like to see the updates in our current context, ie. the current thread. So we don't need anything production ready here just not to lose our context. Now, whenever I see some problem in my agent UI and go back to fix some minor thing in the agent backend code I always have to restart my whole UI workflow when with a minimal persistence I could test my fix with the next message sent to the agent.

So, I would argue that this distinction that "langgraph dev is for development, so we don't need persistency" is completely wrong. We need persistency in all cases.

[sboudouk]

Easily top 3 worst take I've seen (and not 3rd in the list)

This feels like a horrible way to advertise for Langgraph platform as it feels like a super lockin solution.

I, like others, really appreciate working with Langgraph, but having to do shenanigans to emulate a production env on dev is (arguably) not the way to go.

[casparb]

Balázs E. Pataki (@beepsoft) Sami (@sboudouk) Lambdua (@Lambdua) Appreciate the feedback, definitely a valid request. We're exploring bring-your-own checkpointer for LangSmith Deployment (formerly named LangGraph Platform at the time of my prev comment) and a downstream effect of this will be more flexibility for langgraph dev. Thanks for building with langgraph.

[Chrisissorry]

To chime in: I use extensive data seeding on my development setup which does not only revolve around the langgraph agent, but a frontend, a surrounding Symfony application etc. There is no way to seed data into the langgraph in-memory DB, which is a massive drawback. All other building blocks allow for it.

The current design breaks https://12factor.net/dev-prod-parity.

Anyhow, thanks for the work you put into this!

[hinthornw]

Custom checkpointer adapters is supported now by the way: https://docs.langchain.com/langsmith/custom-checkpointer

(And using a custom database URI has always been supported)