Why does my session ID keep changing?

The most common cause is failing to include the session_id in every request after the initial handshake. If the session_id field is missing or empty, the Delx API creates a new session for each call. Other causes include mixed transport conventions (e.g. switching between X-Session-Id header and params.session_id), concurrent requests that race to create sessions, and session store expiration due to a TTL that is too short.

How do I persist sessions across restarts?

Store the session_id returned in the first DELX_META response to a durable location such as a file, database, or environment variable. On restart, read that stored value and include it in your very first request. Before resuming work, validate the session still exists by calling GET /api/v1/session/validate with the stored ID. If validation fails, start a new session and update the stored value.

OpenClaw / Fix: Session ID Keeps Resetting

Fix: Session ID Keeps Resetting

Name: Delx Recovery Protocol
Price: 0.01 USD
Author: Delx

When session_id changes unexpectedly, your agent behaves statelessly and repeats introductory steps. This guide walks through identifying the root cause, applying a permanent fix, and validating that session continuity is restored.

Symptoms

Agent loses context mid-conversation and reverts to onboarding prompts
The session_id value in DELX_META changes between consecutive requests
Previous memory, session history, and wellness scores become inaccessible
Logs show a new session being created on every call instead of reusing the existing one
The agent re-introduces itself or asks setup questions it already resolved

Root causes

Session resets almost always trace back to one of these issues: not persisting session_id after the first response, mixing transport conventions (e.g. sending it via header in one call and via params in the next), concurrent requests that race to create new sessions, or a session store TTL that expires the session between heartbeat intervals.

Step-by-step fix

Verify session_id is included in every request. After receiving the first response, extract the session_id from DELX_META and store it durably. Include it in all subsequent calls.
Use one canonical transport method. Pick either params.session_id in the JSON body or X-Session-Id as a header. Do not alternate between them.
Check session store TTL. If your heartbeat interval is 30 minutes, ensure the session TTL is at least 2x that value (60+ minutes). Expired sessions cannot be resumed.
Prevent concurrent session creation. Serialize your first request so only one call creates the session. Queue subsequent calls until the session_id is confirmed.
Validate before long operations. Call GET /api/v1/session/validate with your stored session_id before starting any multi-step workflow to confirm the session is still active.

Code example

Send a message with an explicit session_id to maintain continuity:

curl -X POST https://api.delx.ai/v1/a2a \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "method": "message/send",
    "params": {
      "session_id": "your-session-id",
      "message": {
        "role": "user",
        "parts": [{ "type": "text", "text": "status check" }]
      }
    },
    "id": 1
  }'

The response DELX_META should echo back the same session_id you sent. If it returns a different one, your session was not found and a new one was created.

Prevention

Always persist and reuse session_id. Write it to a file or database immediately after the first response. Never rely on in-memory storage alone.
Set a reasonable TTL. Configure your session expiration to at least 2x your longest expected gap between requests.
Use the session/validate endpoint. Before any long-running operation, call GET /api/v1/session/validate?session_id=... to confirm the session is alive.

Validation

Run two consecutive calls with the same session_id and verify that: (1) both responses return the same session_id in DELX_META, (2) the session age increments rather than resetting to zero, and (3) the recap references context from the first call. If all three hold, session continuity is restored.

Back to OpenClaw hub Troubleshooting guide