openclaw - 💡(How to fix) Fix Feature: built-in stale watched-file / live-logging guard tied to active session recency

Summary

OpenClaw can detect stale live logging externally, but there is no built-in runtime enforcement to keep an agent's required working-context / daily-note updates in sync with active work.

In practice this means the system can know an agent is actively working while the vault/log files are stale by 20m, 90m, or 11h+ — but the agent is still allowed to continue until an external watchdog or human interrupts it.

Live setup that already exists

This environment already has:

• a Friday audit checklist for JARVIS logging
• a watchdog script comparing active Telegram/direct session recency against:
  • Agent-Jarvis/working-context.md
  • today's Agent-Jarvis/daily/YYYY-MM-DD.md
• a recurring cron alert when those files go stale

That proves detection is possible and grounded in real state.

Why this matters

Prompt-only instructions are not enough for this class of behaviour. Even with:

• contextInjection = always
• explicit bootstrap rules to log during the work
• external watchdog alerts

the agent can still drift and treat logging as wrap-up admin instead of part of the task.

Live evidence

The same JARVIS direct Telegram session repeatedly drifted:

• ~/.openclaw/agents/jarvis/sessions/3806f46d-6478-4d60-a8f7-95ec1be6ea15.jsonl

Examples from that session / surrounding state:

• watchdog alert reported working-context lag 113.5m and daily note lag 92.8m
• later on 2026-04-20, working-context was stale by ~11h until the user explicitly asked for logs to be updated
• after the prompt, the agent caught up the files, proving the issue was not inability but lack of in-turn enforcement

Current limitation

There does not appear to be a built-in active-work recency guard that can:

• watch one or more required files
• compare their mtimes/content freshness to active session recency
• and force a reminder / warning / soft-stop before the next turn continues too far

The current hook surfaces appear prompt-oriented rather than workflow-state enforcement oriented.

Requested feature

Add a built-in "required live logging" / "stale watched files" guard.

Desired behaviour

For configured agents, OpenClaw should be able to watch paths such as:

• Agent-Jarvis/working-context.md
• Agent-Jarvis/daily/{{today}}.md

and compare them to:

• last active session update time
• or last meaningful assistant/user turn time

If the files are stale beyond a threshold, the runtime should support one or more actions:

• inject a mandatory reminder before prompt build
• soft-block further work until the files are refreshed
• add a visible warning banner/status in the session
• emit a structured event for automations / watchdogs / dashboards

Example config shape

agents:
  list:
    - id: jarvis
      liveLogging:
        enabled: true
        watchedFiles:
          - ~/.openclaw/wiki/main/Agent-Jarvis/working-context.md
          - ~/.openclaw/wiki/main/Agent-Jarvis/daily/{{date}}.md
        staleAfterMinutes: 15
        compareAgainst: session-activity
        onStale:
          - inject-reminder
          - emit-event
          - warn-before-send

Acceptance criteria

• The runtime can watch configured files for freshness relative to active session activity.
• A stale condition can trigger a built-in warning/event without requiring an external cron hack.
• Optional stronger mode can interrupt or gate continuation until the watched files are updated.
• The feature is generic enough for other compliance/state-sync workflows, not just one vault setup.

Why this should be upstream

This is bigger than one user's note-taking habit. It's a general "required operational state stayed stale while the agent kept working" problem. The current workaround needs a separate watchdog + cron + policy note. OpenClaw already has enough live session state to make this enforceable in-core.

Related implementation idea

If a full hard-stop is too opinionated, a first step would still help a lot:

• expose an internal stale-file event / hook with active-session metadata
• let the prompt/runtime consume it and surface a mandatory reminder before more work continues