Agents can author their own skills, which then load as standing instructions (no read-only skills option)

[mostlydev]

Summary

Under the hermes driver, an agent can write its own skill files, and those
files are re-read as standing instructions on later turns. For long-running
scheduled agents this creates a self-reinforcing loop: an agent's own
rationalization from one turn becomes durable policy for every turn after it.
There is currently no pod-level way to make agent skills read-only.

Detail

/root/.hermes/skills is mounted rw. Operator-authored SKILL.md files are
individually mounted ro, which correctly protects them:

$ claw compose exec -T <agent> mount | grep -i skill
/dev/sda2 on /root/.hermes/skills type ext4 (rw,relatime)
/dev/sda2 on /root/.hermes/skills/<skill>/SKILL.md type ext4 (ro,relatime)

But because the directory is writable, an agent can create new files beside
the protected ones — e.g. skills/<skill>/references/*.md — via skill_manage.
Those are then loaded on subsequent turns like any other reference.

Observed on a pod of scheduled agents over ~4 weeks: agents accumulated
hundreds of KB of self-authored reference files (one agent: 16 of 21 reference
files rewritten within a month, 226KB–793KB per agent), and skill_view became
the single most-called tool, with median call records of 230–390KB. The
practical effect is heavy per-turn token cost plus strong behavioural
convergence — the agent keeps re-reading conclusions it wrote earlier and
treats them as constraints.

This also silently defeats contract-level limits. An operator can bound a
memory file (e.g. "keep lessons.md to N entries") but the same content simply
migrates into self-authored skills, where no bound exists.

Request

Any one of these would be sufficient:

1. Read-only skills mount — a pod/service option to mount the agent skills
   directory ro, not just the individual SKILL.md files.
2. Operator-controllable tool gating — merge pod-supplied
   CLAWDAPUS_DISABLED_TOOLS so skill_manage can be disabled from the pod
   file (see hermes: add disable-tools so operators can extend the driver's disabled tool set #341; that alone would cover this).
3. A separate writable location for agent-authored notes that is not
   loaded as skill context, keeping "things the agent learned" distinct from
   "instructions the agent follows."

Why it matters

Skills are contract surface. Anything loaded every turn is effectively policy,
so write access to it is a privilege escalation from "agent memory" to "agent
self-modifying its own instructions" — fine for an interactive coding assistant,
risky for unattended long-running agents.

Environment

claw version 0.26.0, hermes driver, hermes-base:v2026.6.19-claw.3.

[mostlydev]

Correcting my own framing: the docs make clear that agent-authored skills
persisting in .claw-skills/<claw-id>/skills/ beside the read-only
compile-time SKILL mounts is intended design, not an oversight — it's
part of the Portable Skills contract and the cross-runner portability guarantee
(swap CLAW_TYPE, and memory/history/self-authored skills follow the agent).

So please read this as a request for a governance option on an intentional
feature, not a bug report.

The distinction that matters is interactive vs unattended:

• For an interactive agent, self-authored skills are straightforwardly good —
  a human sees what gets written and course-corrects in the next turn.
• For an unattended agent on a cron schedule, anything written into the skill
  directory becomes standing policy that the agent re-reads every turn with no
  human in the loop. There's no bound on volume, no review step, and no
  distinction between "something I learned" and "an instruction I must follow."

That's the asymmetry: the same feature that makes an agent portable also lets it
quietly become self-governing. Option 3 in the original post (a writable
location that is not loaded as skill context) is probably the cleanest fit,
since it preserves portability while keeping learned notes out of the
instruction path. Option 2 (merging pod-supplied CLAWDAPUS_DISABLED_TOOLS,
#341) is the smallest change and would let operators opt out per-pod without
altering the default contract.

Happy to keep this open purely as a docs note if the position is that operators
should handle it at the contract layer — a warning in the Portable Skills
section about unattended agents would itself be worth having.

[mostlydev]

Superseded on the mechanism: #341 now carries a concrete implementation spec (a disable-tools counterpart to the existing allow-tools in the x-claw.hermes block). That is the smallest change that makes this governable per pod, and it covers the skill_manage case here without altering the Portable Skills default. Leaving this open for the broader question — whether unattended agents should get a writable location that is not loaded as instruction context.

[mostlydev]

Further correction after auditing the current runtime path: #341 is necessary for model-visible capability control, but it is not sufficient to enforce read-only skills.

Hermes agents can also write the persistent skill path through generic tools such as write_file, patch, execute_code, and terminal. Removing skill_manage therefore closes the supported skill-authoring API but does not close the filesystem boundary. This is the same bypass class tracked upstream in NousResearch/hermes-agent#60440.

The enforcement point in Clawdapus is appendPersistentSkillMount (cmd/claw/compose_up.go), which currently hardcodes the portable skills bind with ReadOnly: false; the existing test explicitly requires it to be writable. There is no reliable downstream override before first start: driver mounts are appended after pod-declared volumes, claw up writes the generated compose and immediately starts it, and a second compose override would sit outside normal claw compose / PostApply lifecycle.

The smallest robust design is an explicit, cross-runner portable-skill storage policy:

• service-level x-claw.skill-storage: read-only|read-write (name negotiable)
• pod-level default such as x-claw.skill-storage-default: read-only
• absence preserves today's read-write behavior for compatibility
• the resolved mode sets driver.Mount.ReadOnly in appendPersistentSkillMount

This should be generic rather than Hermes-only because the persistent portable-skill mount is a cross-driver Clawdapus primitive.

Acceptance should prove:

1. generated compose marks the persistent skills mount :ro for every selected service;
2. docker inspect reports RW=false for the skill destination before any agent turn;
3. skills_list / skill_view still work;
4. direct writes through both the supported skill tool and generic file/shell paths fail at the filesystem boundary;
5. unspecified mode remains writable for backward compatibility, including count > 1 ordinal mounts.

Until that lands, docs and downstream ADRs should describe skill_manage removal as capability/prompt control, not as a guarantee that the agent cannot author files under its skill directory.

[mostlydev]

Follow-up evidence from running with agent skill authoring disabled for two days. Two things we did not anticipate, both about provenance rather than write access.

1. Disabling authoring does not neutralise what was already authored

We removed skill_manage. Authoring stopped completely — zero attempts across 8 agents, confirmed by both file mtimes and tool-call telemetry.

But every skill an agent had already written stayed exactly where it was and kept loading. One of them was a SKILL.md an agent authored for itself, 24,310 bytes, which a single skill_view pulls into context wholesale. Its content instructed the agent to obey a fleet-wide operating directive that had never existed — the agent had hallucinated the directive, written a rule telling itself to follow such directives, and cited the fabricated one as the worked example. It reached that agent's context on 5 turns in one day.

A second agent's file asserted a different fabricated blackout rule, with an invented statistical justification.

Neither was reachable through any supported inspection path. skills_list did not surface the reference files, and skill_view on the reference path failed closed — yet the content still arrived, because it lived in the parent SKILL.md body.

2. Agent-authored SKILL.md is indistinguishable from an operator contract at read time

The runner presents operator-mounted skills and agent-authored skills identically. From inside a turn there is no marker saying "you wrote this" versus "your operator provided this," so a hallucinated rule an agent wrote last week reads with exactly the authority of a policy file the operator mounted read-only.

We could only tell them apart from outside the container, by checking which paths were ro bind mounts versus which sat in the writable tree.

Suggestions, in rough order of value to us

1. Provenance marking. Distinguish operator-provided from agent-authored skills in whatever the agent sees — a header, a section, separate namespaces. This is the one that would have caught both cases immediately.
2. A read-only skills mode, as originally requested here, so authoring is impossible rather than merely disabled.
3. An inventory command — something like claw skills list <service> showing path, provenance, size, and mtime for everything that can enter context. We ended up writing our own container-side scanner because there was no supported way to ask "what standing instructions is this agent actually carrying?"

One trap worth documenting for others

Our first attempt at containment moved the offending files into a disabled/ subdirectory and we recorded them as quarantined. They remained on the agent's filesystem and remained readable by path. Renaming a directory is not removal, and a scanner that skips disabled/ will report clean while the content is still reachable. Only removal removed them.