cllama: session-history and context-ledger files should not be root-only on host mounts

[mostlydev]

Summary

A live Tiverton debugging session found .claw-session-history artifacts created with root-only ownership/permissions, preventing the normal host operator user from running claw audit and claw history export.

This blocks exactly the commands operators need when debugging provider-visible context, feed fetches, and channel-context cursors.

Live evidence

Host/repo: tiverton:tiverton-house
Date: May 11, 2026
Runtime: claw-api/claw-wall/clawdash v0.14.8, cllama v0.6.4
Operator user: clawdbot

Commands that failed as the normal host user:

$ claw audit --since 4h --claw boulton --type feed_fetch --json
Error: open session history "/home/clawdbot/tiverton-house/.claw-session-history/context-ledger/history.jsonl": permission denied

$ claw history export boulton --after 2026-05-11T11:00:00Z --limit 20
Error: open /home/clawdbot/tiverton-house/.claw-session-history/boulton/history.index.json: permission denied

Filesystem state:

drwxrwxr-x 11 clawdbot clawdbot ... .claw-session-history
drwx------ 10 root     root     ... .claw-session-history/context-ledger

A Docker-root workaround could still read data like .claw-session-history/context-ledger/boulton/cursor.json, so the files existed; they were just inaccessible to the operator user and normal claw diagnostics.

Why this matters

The incident being debugged was a channel-context/cursor visibility mismatch. The correct investigation path was to inspect:

• feed_fetch audit events;
• context-ledger cursor values;
• exported session history;
• provider-visible context snapshots/logs.

Those are operator/debugging surfaces, so they need to be readable by the same user expected to operate claw in the repo checkout. Requiring interactive sudo or ad hoc Docker-root commands is too fragile for live pod operations.

Suspected cause

The cllama/container process writes some host-mounted .claw-session-history files as root, or creates parent directories with root-only permissions. Downstream pods can patch around that with post-start normalization, but the default should preserve host-level operability.

This may affect at least:

• .claw-session-history/context-ledger/
• .claw-session-history/context-ledger/history.jsonl
• .claw-session-history/<agent>/history.index.json
• related per-agent history files used by claw history export

Proposed fix

Ensure session-history and context-ledger artifacts are created with host-operable ownership/permissions.

Possible implementation directions:

• Run the writer with the intended runtime UID/GID when writing bind-mounted session history.
• Chown/chmod created session-history paths after writes using the configured host/runtime user mapping.
• Make claw up or the relevant runtime materialization step create .claw-session-history subdirectories with safe group-readable/traversable permissions before containers start.
• Add a repair path in claw diagnostics if legacy root-owned files are detected.

The exact mechanism can vary by driver/runtime, but the contract should be: a non-root host operator who can run claw compose in the project can also run claw audit and claw history export without permission errors.

Acceptance criteria

• In a pod using cllama session history/context-ledger on a bind mount, the host operator user can run:
  • claw audit --since 4h --claw <agent> --type feed_fetch --json
  • claw history export <agent> --after <timestamp>
• .claw-session-history/context-ledger is traversable/readable enough for those commands without world-opening unrelated secrets.
• New files are not created as root-only on subsequent turns.
• Existing root-owned legacy trees can be repaired through a documented or automated path.
• Add a regression test or integration smoke that checks file ownership/permissions from the host side after an agent turn writes history/cursor state.

Related downstream hardening

Tiverton is adding local script hardening so live deploy/restart paths normalize .claw-session-history permissions, but that is a workaround. The upstream runtime should avoid creating host-mounted debug artifacts that the host operator cannot read.

[mostlydev]

Additional implementation notes, keeping this generic rather than tying it to any downstream pod:

• The narrow failure shape is context-ledger becoming owned by the container/runtime writer while remaining 0700, so the normal host operator cannot traverse .claw-session-history/context-ledger and commands such as claw audit --since ... fail before they can inspect history.
• A host-side repair that chowns context-ledger back to the operator UID/GID makes 0700 workable; the important invariant is not world-readable permissions, it is that the same non-root operator expected to run claw can read/traverse the runtime-owned diagnostics tree.
• The fix should cover subsequent writes, not only initial directory creation. Per-agent cursor.json files under context-ledger/<agent>/ should stay readable by the operator after agent turns and restarts.
• A useful regression check would be: start a pod, trigger a turn that writes channel/session ledger state, then run claw audit --since 10m --json and claw history export <agent> --limit 1 as the non-root host operator. Neither should need sudo or a Docker-root workaround.
• If legacy ownership is detected, the CLI should emit a direct repair hint or provide a repair command instead of surfacing only a raw permission denied path.