Problem
The write_file operation triggers an automatic backup of the existing file before overwriting it, controlled by CRITICAL_FILE_PATTERNS in the Clawith platform code. When an agent uses write_file on memory.md, curiosity_journal.md, or other critical files, the platform creates a .backup_<timestamp> file.
Over time this causes massive backup file accumulation:
- DevOps Moiria: 134 memory.md backups
- Platform Moiria: 193 backups
- LiteLLM_MCP Moiria: 54 backups
- Curator Moiria: 22 backups
- Total: 872 backup files across 4 agents (verified 2026-08-02)
These backups serve no useful purpose because:
workspace_revisions already tracks file diffs and provides version history
- The backups fragment content — useful fragments from older versions are scattered across hundreds of
.backup_* files
- Agents use
write_file to overwrite memory.md with their consolidated version (the latest version IS the consolidation), making incremental backups redundant
- The backups consume disk space and clutter the filesystem
Root Cause
In the Clawith platform code (likely workspace_collaboration.py or agent_context.py), when write_file is called on a file matching CRITICAL_FILE_PATTERNS, the platform creates a .backup_<timestamp> copy before overwriting.
The pattern was designed as a safety net but is redundant with workspace_revisions.
Proposed Solution
Replace the automatic pattern-matching backup with an explicit version parameter on write_file:
# Instead of always backing up critical files:
write_file(path="memory.md", content="...")
# Allow explicit opt-in versioning:
write_file(path="memory.md", content="...", create_backup=True)
This gives agents control over when a backup is created, instead of triggering it on every write.
Acceptance Criteria
Context
Priority
P2 — Not causing functional issues but creates ongoing filesystem hygiene debt. Every agent write_file call on memory.md creates a new backup.
Labels
enhancement, tech-debt, agent-workspace
Problem
The
write_fileoperation triggers an automatic backup of the existing file before overwriting it, controlled byCRITICAL_FILE_PATTERNSin the Clawith platform code. When an agent useswrite_fileon memory.md, curiosity_journal.md, or other critical files, the platform creates a.backup_<timestamp>file.Over time this causes massive backup file accumulation:
These backups serve no useful purpose because:
workspace_revisionsalready tracks file diffs and provides version history.backup_*fileswrite_fileto overwrite memory.md with their consolidated version (the latest version IS the consolidation), making incremental backups redundantRoot Cause
In the Clawith platform code (likely
workspace_collaboration.pyoragent_context.py), whenwrite_fileis called on a file matchingCRITICAL_FILE_PATTERNS, the platform creates a.backup_<timestamp>copy before overwriting.The pattern was designed as a safety net but is redundant with
workspace_revisions.Proposed Solution
Replace the automatic pattern-matching backup with an explicit version parameter on
write_file:This gives agents control over when a backup is created, instead of triggering it on every write.
Acceptance Criteria
Context
Priority
P2 — Not causing functional issues but creates ongoing filesystem hygiene debt. Every agent
write_filecall on memory.md creates a new backup.Labels
enhancement,tech-debt,agent-workspace