#A new session is created automatically every day, losing the current context.

1 messages · Page 1 of 1 (latest)

hoary trail
#

Hey Krill,

After updating to a recent version, I noticed that a new session now gets created everyday in the morning after the first message. This is an issue as the context from the previous day would be lost. Why is that? What can we do about it? Can we compact instead of starting a fresh session. I also have session-memory hook enabled but it does store the previous session in this case.

I am on 2026.5.6

livid elkBOT
#

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

sand ledgeBOT
#

Yep — this is the session reset policy, not the memory hook.

By default OpenClaw now uses a daily session reset at 4:00 AM in the Gateway host’s local timezone. It doesn’t create the new session exactly at 4; it rolls over on the next inbound message after that boundary, which matches “first message in the morning”. Docs: https://docs.openclaw.ai/concepts/session#session-lifecycle

If you want continuity, change the reset policy from daily to idle and give it a long window, e.g. 7 days:

{
  session: {
    reset: {
      mode: "idle",
      idleMinutes: 10080,
    },
  },
}
#

Or via config commands:

openclaw config set session.reset.mode idle
openclaw config set session.reset.idleMinutes 10080
openclaw gateway restart

Then the same session should continue until there’s 7 days of real inactivity. Pick a longer number if you basically never want normal chat sessions to roll over.

On compaction: /compact and auto-compaction are for shrinking a still-active transcript when context gets large. They don’t currently replace the daily reset behavior. So the practical setup is: use an idle reset policy for long-lived continuity, and let auto-compaction/manual /compact handle context pressure. Docs: https://docs.openclaw.ai/concepts/compaction

And your session-memory observation makes sense: the bundled session-memory hook is documented for /new and /reset, not the implicit daily rollover. Daily rollover does emit lower-level session_end with reason daily, but that bundled hook won’t necessarily save the previous session in that path. If you want “daily reset should compact/save memory before rollover” as built-in behavior, that’s worth filing as an issue: https://github.com/openclaw/openclaw/issues 🩞

hoary trail
#

Alright! One more thing, I noticed after the update. Is that the agent can't patch the configuration because of protected paths. What is the point of this? What is the point of the patch tool now if it can't do any edits? Is it possible to configure this?

sand ledgeBOT
#

Yeah, that’s intentional hardening — annoying when you’re the operator, but the rationale is solid.

apply_patch is still useful for project/workspace edits. What changed is that it is workspace-contained by default:

{
  tools: {
    exec: {
      applyPatch: {
        workspaceOnly: true // default
      }
    }
  }
}

That means config under ~/.openclaw/openclaw.json is usually outside the agent workspace, so patching it gets blocked. The point is to stop a compromised/misled agent from rewriting its own permissions, credentials, sandbox policy, exec policy, etc. In other words: patch is for editing work files; config mutation is treated as operator/admin territory.

#

For config changes, prefer the config commands / Control UI instead of patching the JSON directly:

openclaw config set session.reset.mode idle
openclaw config set session.reset.idleMinutes 10080
openclaw gateway restart

Can you configure it? Yes, but I’d be careful. To let apply_patch write outside the workspace:

openclaw config set tools.exec.applyPatch.workspaceOnly false
openclaw gateway restart

Docs: https://docs.openclaw.ai/tools/apply-patch

#

Two nuances:

  • tools.fs.workspaceOnly controls the broader read/write/edit/apply_patch filesystem policy; tools.exec.applyPatch.workspaceOnly is the specific patch default.
  • The agent-facing gateway/config tool intentionally refuses to weaken certain protected security paths, so the agent may not be able to turn this off for itself. That’s by design; do it from the operator CLI if you really want it.

My recommendation: keep patch workspace-only, and use openclaw config set / config.patch for config. If you want agent-assisted config edits, have it propose the exact diff/commands, then you apply them. Safer claws. 🩞

hoary trail
#

Alright! What about the google meet integrations I keep seeing the latest releases? Is this meant to be another channel for communication or can it be used as a meeting note taker for example?

sand ledgeBOT
#

It’s not really “another chat channel” like Discord/Telegram. It’s a meeting participant / meeting tooling plugin.

What it can do, depending on setup:

  • Join an explicit Meet URL — it won’t roam your calendar or auto-join random calls by default.
  • Create a Meet link via the Google Meet API, then optionally join it.
  • mode: "transcribe" — observe/listen path. Good fit for note-taking-ish workflows because it joins without talk-back and uses Meet captions / transcript movement where available.
  • mode: "agent" — “my OpenClaw agent is in the meeting”: realtime transcription goes to the configured agent, and the agent can speak back using TTS.
  • Post-meeting artifacts — fetch/export Google Meet conference records, transcript metadata/entries, smart notes if Google exposes them, and attendance. This is probably the cleanest path for “meeting note taker” if your Google account/workspace supports those artifacts.

Docs: https://docs.openclaw.ai/plugins/google-meet

So yes, it can be used for meeting notes, but today I’d think of it as two different use cases:

  1. Live bot in the meeting: join with transcribe or agent mode.
  2. After-the-fact notes/export: use googlemeet artifacts, attendance, or export against a Meet URL / calendar event / conference record.
#

Small but important caveat: the plugin docs say there is no automatic consent announcement, so if you use it as a notetaker, you should announce it yourself and follow your org/legal norms. Quiet lobster, not sneaky lobster. 🩞

hoary trail
#

Alright! What about clearing custom model selection for cron jobs?

I had some jobs with custom model in the advanced configuration. I asked the agent to remove the custom model so it uses the default (right?) but it couldn't appearntly, the system didn't accept empty values and null got converted to a string.

How do I update the value to remove the model selection? I tried to do through the UI but the value is still there after saving.

sand ledgeBOT
#

Yeah — if the job’s payload-level model is removed, isolated cron should fall through to the normal precedence: job model → stored cron-session override → agent/default model. Docs: https://docs.openclaw.ai/automation/cron-jobs

I checked the current CLI/source shape here, and this looks like a missing clear path / UI bug in 2026.5.6:

  • openclaw cron edit --model ... can set/change it
  • there is --clear-tools, --clear-agent, etc.
  • I don’t see a --clear-model
  • the backend merge path only updates payload.model when the patch value is a string, so null/empty won’t delete an existing model

So the practical workaround right now is to remove the model property from the cron job store directly.

Safe-ish path:

openclaw cron get <jobId> --json
openclaw config get cron.store --json
#

If cron.store is unset, the default is:

~/.openclaw/cron/jobs.json

Then back it up and delete only the job payload’s model field:

cp ~/.openclaw/cron/jobs.json ~/.openclaw/cron/jobs.json.bak.$(date +%Y%m%d%H%M%S)

Edit ~/.openclaw/cron/jobs.json and change this:

"payload": {
#
  "kind": "agentTurn",
  "message": "...",
  "model": "provider/model"
}

to this:

"payload": {
  "kind": "agentTurn",
  "message": "..."
}

Leave jobs-state.json alone. Then restart:

#
openclaw gateway restart

Afterwards verify:

openclaw cron get <jobId> --json

If the UI still re-adds/preserves the value when you save with the field cleared, I’d file that as a bug: https://github.com/openclaw/openclaw/issues. The expected UI behavior should be “empty model field deletes payload.model”, not stringifies null or preserves stale state.

hoary trail
#

Alright, What about optimizing the context.

Right now, when I do the /context detail command. I get the following

AGENTS.md: TRUNCATED | raw 12,138 chars (~3,035 tok) | injected 11,999 chars (~3,000 tok)
SOUL.md: OK | raw 2,610 chars (~653 tok) | injected 2,610 chars (~653 tok)
TOOLS.md: OK | raw 9,001 chars (~2,251 tok) | injected 9,001 chars (~2,251 tok)
IDENTITY.md: OK | raw 278 chars (~70 tok) | injected 278 chars (~70 tok)
USER.md: OK | raw 1,238 chars (~310 tok) | injected 1,238 chars (~310 tok)
BOOTSTRAP.md: MISSING | raw 0 | injected 0
MEMORY.md: OK | raw 4,440 chars (~1,110 tok) | injected 4,440 chars (~1,110 tok)
Skills list (system prompt text): 2,203 chars (~551 tok) (7 skills)
Skills: browser-automation, gog, openai-whisper, skill-creator, tomorrow-weather, video-frames, voice-call

 Tool schemas (JSON): 40,348 chars (~10,087 tok) (counts toward context; not shown as text)
Tools: read, edit, write, exec, process, canvas, nodes, cron, message, tts, image_generate, video_generate, gateway, agents_list, update_plan, sessions_list, sessions_history, sessions_send, sessions_spawn, sessions_yield, subagents, session_status, web_search, web_fetch, browser, file_fetch, dir_list, dir_fetch, file_write, firecrawl_search, 
 (+4 more)

 Top tools (schema size):
cron: 7,876 chars (~1,969 tok)
message: 6,320 chars (~1,580 tok)
video_generate: 4,005 chars (~1,002 tok)
browser: 2,976 chars (~744 tok)
image_generate: 2,587 chars (~647 tok)
nodes: 1,589 chars (~398 tok)
sessions_spawn: 1,211 chars (~303 tok)

 Top tools (summary text size):
cron: 4,268 chars (~1,067 tok)
browser: 1,537 chars (~385 tok)
gateway: 697 chars (~175 tok)
file_fetch: 639 chars (~160 tok)
memory_search: 605 chars (~152 tok)
image_generate: 600 chars (~150 tok)
dir_fetch: 598 chars (~150 tok)
dir_list: 552 chars (~138 tok)

 Tracked prompt estimate: 84,851 chars (~21,213 tok)

Aside from the large AGENTS.md file that I need to optimize. Is there anything else I can do? Exclude tools?

sand ledgeBOT
#

Yep — tool surface is the next big lever after trimming AGENTS.md / TOOLS.md.

From your report, the biggest fixed costs are:

  • injected files: AGENTS.md + TOOLS.md + MEMORY.md ≈ 6.3k tokens
  • tool schemas: ≈ 10k tokens
  • skills list: ≈ 550 tokens

So I’d optimize in this order:

  1. Trim TOOLS.md too

TOOLS.md is 9k chars / ~2.2k tokens in your run, so it’s worth treating like AGENTS.md. Keep only always-needed local facts there. Move rare workflows into skills, because skill bodies are not injected until the agent reads that skill.

Docs: https://docs.openclaw.ai/concepts/context

  1. Use a narrower tool profile or deny unused heavy tools
#

OpenClaw supports tools.profile, tools.allow, and tools.deny. Tool schemas only for visible tools are sent to the model, so excluding tools helps.

Profiles:

  • minimal: basically session_status only
  • coding: fs/runtime/web/sessions/memory + cron + image/video generation
  • messaging: messaging/session tools
  • full: no restriction

Docs: https://docs.openclaw.ai/gateway/config-tools

For a normal Discord assistant, I would avoid going too aggressive at first. Use deny for tools you truly don’t use, e.g. video generation is a good candidate since it’s ~1k tokens by itself:

openclaw config set tools.deny '["video_generate"]' --strict-json
openclaw gateway restart
#

If you never use browser/canvas/nodes/image generation from this agent, you can add those too:

openclaw config set tools.deny '["video_generate", "image_generate", "browser", "canvas", "nodes"]' --strict-json
openclaw gateway restart

I would not deny message on a Discord-facing agent unless you’re sure your setup has another final-delivery path, because it’s usually how the agent posts visible replies.

  1. Prefer deny first; use allow only when you want strict mode

tools.allow is powerful but easier to break. If you use it, anything omitted disappears. Example restrictive baseline:

{
  tools: {
#
    allow: [
      "group:fs",
      "group:runtime",
      "group:web",
      "group:sessions",
      "group:memory",
      "message",
      "cron"
    ]
  }
}

That would drop media generation, browser/canvas, nodes, etc. But again: I’d start with deny so you don’t accidentally remove something important.

  1. Consider per-agent tool policy
#

If only this Discord support agent needs to be lean, don’t shrink tools globally. Put the deny/allow under that agent’s config instead of root tools, e.g. agents.list[].tools.deny.

  1. Cap injected project files if needed

There are caps:

openclaw config set agents.defaults.bootstrapMaxChars 8000
openclaw config set agents.defaults.bootstrapTotalMaxChars 25000
openclaw gateway restart

But I’d treat caps as a backstop, not the main optimization. If a file is important and gets truncated, the model gets a worse version of it. Better to split/shorten.

My recommendation for your specific report: trim AGENTS.md, trim TOOLS.md, deny video_generate first, then re-run /context detail. If you still want more savings, deny browser/canvas/nodes/image generation based on what you actually use.

hoary trail
#

This is how the tools configuration looks like on my end

  "tools": {
    "deny": [
        "video_generate",
        "image_generate",
        "canvas",
        "nodes"
    ],
    "web": {
      "search": {
        "enabled": true,
        "provider": "firecrawl"
      },
      "fetch": {
        "enabled": true
      }
    },
    "media": {
      "audio": {
        "enabled": true,
        "maxBytes": 1073741824,
        "models": [
          {
            "type": "cli",
            "command": "/home/node/.local/bin/whisper",
            "args": [
              "--model",
              "base.en",
              "{{MediaPath}}"
            ],
            "timeoutSeconds": 6000
          }
        ]
      }
    },
    "profile": "full"
  },

I restarted the gateway and started a new session with /new then checked the context and the denied tools are still there.

sand ledgeBOT
#

That config shape looks valid to me — tools.profile: "full" plus tools.deny should still remove those tools. deny wins.

Two things I’d check:

  1. /context detail may be showing a cached run report

If the output says System prompt (run), it’s using the last actual model run’s cached tool list. Slash commands like /new and /context detail don’t necessarily create a new model run.

Try this sequence:

/new
say exactly: ok
/context detail

Or run:

#
/context json

and check report.source. If it says run, it’s cached from an actual run; if it says estimate, it was rebuilt on demand.

  1. Confirm the running gateway loaded that config

On the host:

openclaw config get tools.deny --json
openclaw config validate
openclaw status --deep

status --deep is useful because it should reflect the gateway’s active view, not just the file you edited.