#debug slug generation fail?

1 messages · Page 1 of 1 (latest)

shadow kindleBOT
#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> âś… Mark Solution

abstract fogBOT
#

“Slug generation” in OpenClaw is (usually) the session-memory hook: when you run /new, it tries to call an LLM to produce a short filename slug, and if that fails it falls back to a timestamp like YYYY-MM-DD-1430.md.

How to debug (quick loop)

  1. Get version first (this matters a lot for hook behavior):

    openclaw --version

  2. Tail logs, then trigger the failure:

    openclaw logs --follow

    Now run /new in chat and watch for hooks/session-memory lines and/or:

    • Calling generateSlugViaLLM...
    • [llm-slug-generator] Failed to generate slug: ...

  3. Also check model/auth resolution (the slug generator is a separate one-off run):

# 
   openclaw models status

If you paste the exact error line from the log, it’ll usually be obvious (timeout vs missing credentials vs provider error).

“Are there config options for slug generation?”

For the bundled hook, the documented one is:

  • hooks.internal.entries.session-memory.messages (how many recent messages it uses)

There’s also an undocumented but supported switch in the handler:

  • hooks.internal.entries.session-memory.llmSlug: false → disables LLM slugging and always uses the timestamp fallback.

Example:

{
# 
  hooks: {
    internal: {
      entries: {
        "session-memory": {
          enabled: true,
          messages: 15,
          llmSlug: false
        }
      }
    }
  }
}

The gotcha (why it “fails while my local model works”)

Right now, the slug generator runs via an embedded agent call that defaults to the built-in provider/model defaults (Anthropic) unless explicitly overridden. So if your chat is using a local model but you don’t have Anthropic creds configured, slug generation can fail and you’ll see the timestamp fallback.

#

Workarounds today:

  • configure Anthropic auth (so the default embedded call can succeed), or
  • set llmSlug: false to skip the LLM step.

Docs reference: https://docs.openclaw.ai/automation/hooks#session-memory

If you drop openclaw --version + the [llm-slug-generator] error line here, I can tell you which path you’re hitting.

tiny cipher
#

17:16:34 debug hooks/session-memory {"length":0,"messageCount":15} Session content loaded
17:16:34 debug hooks/session-memory {"slug":"1716"} Using fallback timestamp slug

abstract fogBOT
#

That log means it never even tried the LLM — it fell back because the hook extracted 0 eligible messages from the previous session transcript:

  • length: 0 → getRecentSessionContent() returned "" (or null, the log can’t distinguish)
  • then sessionContent && cfg && allowLlmSlug is falsy → no generateSlugViaLLM() call → timestamp slug (1716)

Most common reasons

  1. You’re running /new in a session that has no normal text messages yet (or only slash-commands). The extractor explicitly drops text that starts with /.
  2. The session file exists, but the transcript doesn’t match what the hook expects (entry.type === "message" with entry.message.role and a text content block).

What I need next (1 snippet)

In the same log stream, there should be a line right before this like:

debug hooks/session-memory Session context resolved { sessionId, sessionFile, ... }

Paste that line (especially the sessionFile path). Then on the gateway host run:

# 
tail -n 30 "<that sessionFile>"

We’re looking for whether the JSONL lines contain "type":"message" entries and whether message.content contains { "type": "text", "text": "..." } (or something else). If it’s “something else”, that’s likely the bug.

Workaround (if you just want it to stop trying)

You can force timestamp slugs:

hooks: { internal: { entries: { "session-memory": { llmSlug: false }}}}

Also: what version are you on (openclaw --version)?

tiny cipher
#

{"type":"message","id":"3eb67ff8","parentId":"1c1743d8","timestamp":"2026-02-16T17:16:00.817Z","message":{"role":"toolResult","toolCallId":"functions.write:4","toolName":"write","content":[{"type":"text","text":"Successfully wrote 294 bytes to /Users/xxx/.openclaw/workspace/memory/2025-01-21.md"}],"isError":false,"timestamp":1771262160812}}
{"type":"message","id":"5adc3bd5","parentId":"3eb67ff8","timestamp":"2026-02-16T17:16:01.882Z","message":{"role":"assistant","content":[{"type":"thinking","thinking":" I've created the daily memory file. But the user said "slug is not getting created" — this might imply they expected some automation. Let me ask if this is what they meant, or if there's a specific automation/cron they thought should be creating these.","thinkingSignature":"reasoning_content"},{"type":"text","text":" ✅ Created memory/2025-01-21.md. \n\nIs the issue that you expected these to be auto-generated (via cron or similar), or were you just noticing they were missing when I should've been creating them during our sessions?"}],"api":"openai-completions","provider":"local100","model":"mymodel","usage":{"input":15670,"output":107,"cacheRead":0,"cacheWrite":0,"totalTokens":15777,"cost":{"input":0,"output":0,"cacheRead":0,"cacheWrite":0,"total":0}},"stopReason":"stop","timestamp":1771262160817}}

openclaw --version
2026.2.14

abstract fogBOT
#

That log isn’t a “model failed” case yet — it’s earlier in the pipeline:

  • Session content loaded {"length":0,...} means the hook extracted zero eligible user/assistant text from the previous session transcript, so it never calls the LLM, and immediately falls back to the timestamp (1716).

Two important details:

  1. toolResult lines don’t count
    The extractor only keeps role: "user" and role: "assistant" messages (and ignores tool/toolResult). So if the session is mostly tools, it can end up empty.

  2. Your pasted JSONL does contain an assistant text block, so either:

  • the hook is reading a different session file than the one you pasted, or
  • it failed to read/parse the file (the code logs length:0 for both "" and null).

Next step (most useful)

In the gateway logs, right before the “Session content loaded” line, find and paste this debug line:

hooks/session-memory Session context resolved { sessionId, sessionFile, hasCfg, ... }

#

What we need from it:

  • the sessionFile path (verify it’s the file you inspected)
  • whether hasCfg is true (if it’s false, LLM slugging will never run)

Then on the gateway host:

ls -la "<sessionFile>"
tail -n 50 "<sessionFile>"

If that file doesn’t exist → that’s the bug (stale/invalid sessionFile path).
If it exists but contains no parsable type:"message" entries → that’s the bug (format/corruption).
If it exists and has assistant/user text but OpenClaw still extracts nothing → that’s a parsing bug worth a GitHub issue.

Separate gotcha (once extraction works)

On 2026.2.14 the LLM slug generator currently runs via an embedded call that defaults to Anthropic internally; it’s not “use whatever my chat model is”. So local-only installs will still fall back unless Anthropic creds exist (or you disable LLM slugs).

#

Paste that “Session context resolved …” line and we’ll nail which branch you’re hitting.

tiny cipher
#

I dont see a "Session content loaded" in the logs

abstract fogBOT
#

Those hooks/session-memory ... lines are debug-level logs. If your gateway log level is info (default), you won’t see them at all.

1) Check your current log levels

openclaw config get logging.level
openclaw config get logging.consoleLevel

2) Temporarily turn on debug logging (so the hook prints those lines)

openclaw config set logging.level "debug"
openclaw config set logging.consoleLevel "debug"
openclaw gateway restart

Now reproduce: run /new, then tail logs:

# 
openclaw logs --follow

You should see hooks/session-memory entries again.

3) If you still don’t see anything hook-related

Make sure the hook is actually enabled/loaded:

openclaw hooks list
openclaw hooks check

4) (Optional) turn logging back down after debugging

# 
openclaw config set logging.level "info"
openclaw config set logging.consoleLevel "info"
openclaw gateway restart

Docs: https://docs.openclaw.ai/logging and https://docs.openclaw.ai/cli/hooks

If you paste the output of openclaw hooks list (just the session-memory lines) + the first hook log line you get after enabling debug, we can continue from there.

abstract fogBOT
#

That “.jsonl.reset.<timestamp>” rename is the key clue.

What’s happening is:

  1. The session-memory hook logs it’s going to read:

…/sessions/6dd32d1a-….jsonl

  1. But the /new flow then archives/resets that transcript by renaming it to:

…/sessions/6dd32d1a-….jsonl.reset.2026-…

If the hook tries to read the pre-reset filename after the rename already happened, the read fails → it extracts no text → it never calls the LLM → you get the fallback timestamp slug.

Confirm in one command

On the gateway host, run:

# 
ls -la /Users/varoudis/.openclaw/agents/main/sessions/6dd32d1a-8726-4725-836c-2de0b5797c47.jsonl*

If you only see the .reset.… file (and not the plain .jsonl), then the hook is indeed holding a stale path at read time.

What to paste next

In the debug logs right after “Session context resolved”, there should be either:

  • Session content loaded {"length":0,...} (rename/race problem), or
  • Session content loaded {"length":123,...} then Calling generateSlugViaLLM... (next problem: model/auth)

Paste those next 2–3 hook lines and we’ll know which branch you’re on.

Separate issue you’ll hit next (local-only)

Even if the hook successfully reads the transcript, the slug generator currently runs an embedded one-off agent call that defaults to Anthropic (anthropic/claude-opus-4-6) rather than “your local model”. So on a local-only setup it will still often fall back unless Anthropic creds exist.

#

Workaround (if you just want predictable behavior)

Disable LLM slugs and always use the timestamp:

{
  hooks: {
    internal: {
      entries: {
        "session-memory": { enabled: true, llmSlug: false }
      }
    }
  }
}

If you’re up for filing a bug

This looks like a real ordering/path bug (hook gets sessionFile name that is immediately renamed) + a “hardcoded Anthropic default” limitation.

tiny cipher
#

ls -la /Users/varoudis/.openclaw/agents/main/sessions/6dd32d1a-8726-4725-836c-2de0b5797c47.jsonl*
-rw-r--r-- 1 varoudis staff 9137 Feb 16 18:02 /Users/varoudis/.openclaw/agents/main/sessions/6dd32d1a-8726-4725-836c-2de0b5797c47.jsonl.reset.2026-02-16T18-02-58.032Z
(base) varoudis@Tasoss-Virtual-Machine sessions %

18:02:58 debug hooks/session-memory {"subsystem":"hooks/session-memory"} {"length":0,"messageCount":15} Session content loaded
18:02:58 debug hooks/session-memory {"subsystem":"hooks/session-memory"} {"slug":"1802"} Using fallback timestamp slug

abstract fogBOT
#

Yep — you’ve nailed the root cause. This is not your local model failing; it’s a file rename timing bug.

What’s happening

On /new, OpenClaw now archives the old transcript by renaming it to:

<session>.jsonl.reset.<timestamp>

…and it does that before the internal command:new hook (session-memory) tries to read previousSessionEntry.sessionFile.

So the hook tries to read:

…/6dd32d1a-….jsonl (no longer exists)

→ can’t load anything → length:0 → never calls the LLM → falls back to timestamp slug (1802).

Your outputs confirm it perfectly:

  • Session context resolved … sessionFile: …jsonl
#
  • only …jsonl.reset.… exists on disk
  • Session content loaded {"length":0,…}

Workarounds

  1. If you just want it quiet / predictable:
hooks: { internal: { entries: { "session-memory": { enabled: true, llmSlug: false }}}}

(Always uses the timestamp slug.)

  1. Or disable the hook entirely:
openclaw hooks disable session-memory

Next step (recommended): file a bug

This looks like a regression introduced by the “archive old transcript on reset” change. A good fix would be either: