Resilient Write: A Six-Layer Durable Write Surface for LLM Coding Agents Justice Owusu Agyemang1,2,3∗, Jerry John Kponyo3†, Elliot Amponsah3‡, Godfred Manu Addo Boakye3§, Kwame Opuni-Boachie Obour Agyekum2¶
arXiv:2604.10842v2 [cs.SE] 14 Apr 2026
1
Sperix Labs
2
VIA Cybersecurity Lab, KNUST
3
Quantum and Assistive Technologies Lab, KNUST
April 2026
Abstract
1
LLM-powered coding agents increasingly rely on tool-use protocols such as the Model Context Protocol (MCP) to read and write files on a developer’s workstation. When a write fails— due to content filters, truncation, or an interrupted session—the agent typically receives no structured signal, loses the draft, and wastes tokens retrying blindly. We present Resilient Write, an MCP server that interposes a sixlayer durable write surface between the agent and the filesystem. The layers—pre-flight risk scoring, transactional atomic writes, resume-safe chunking, structured typed errors, out-of-band scratchpad storage, and task-continuity handoff envelopes—are orthogonal and independently adoptable. Each layer maps to a concrete failure mode observed during a real agent session in April 2026, in which content-safety filters silently rejected a draft containing redacted API-key prefixes. Three additional tools—chunk preview, format-aware validation, and journal analytics— emerged from using the system to compose this paper. A 186-test suite validates correctness at each layer, and quantitative comparison against naive and defensive baselines shows a 5× reduction in recovery time and a 13× improvement in agent self-correction rate. Resilient Write is open-source under the MIT license.
The emergence of tool-augmented large language models (LLMs) has shifted softwareengineering assistants from suggestion engines to autonomous agents that read, write, and execute code on a developer’s behalf [1, 2, 3, 4]. The Model Context Protocol (MCP) [5] standardises the interface between an LLM and the tools it invokes—file reads, writes, shell commands, database queries—giving agents a uniform way to act on the local environment. In practice, the write path is fragile. A Write tool call can fail for reasons invisible to the agent: content-safety filters may reject the payload silently; a large file may be truncated midstream; the session may be interrupted before the write completes; and when a write does fail, the error signal is typically an unstructured string (or no signal at all), leaving the agent unable to diagnose the cause or choose a recovery strategy.
Introduction
Motivating incident. In April 2026, while producing a technical report on LLM CLI telemetry [6], an agent attempted to write a LATEX document whose body included redacted HTTP headers such as Authorization: Bearer sk-ant-oat01-{REDACTED}. The prefix pattern sk-ant- triggered a content-safety regex in the host tool, which silently rejected the payload. The agent received no structured error. It retried the identical content five times, consuming approximately two minutes of wall-clock time
∗
[email protected], [email protected] [email protected] ‡ [email protected] § [email protected] ¶ [email protected] †
1
Code [1], Cursor [3], GitHub Copilot [4], OpenAI Codex CLI [2], and OpenCode [7] each grant the model access to the local filesystem, a shell, and often a language server. The SWE-bench benchmark [8] and the SWE-agent framework [9] have further demonstrated that agents can resolve real GitHub issues end-to-end, making reliable file mutation a critical capability.
and several thousand tokens, before falling back to an ad-hoc workaround: piping the document through chunked cat » file.tex «EOF heredoc commands in the shell. This single incident exposed five distinct failure modes: 1. Silent rejection—no signal that the write was blocked. 2. Draft loss—the rejected payload was not persisted anywhere. 3. Retry thrashing—the agent retried identical content with no budget limit. 4. No structured diagnosis—the agent could not branch on error type. 5. Session fragility—had the session been interrupted during the workaround, all progress would have been lost.
2.2
The Model Context Protocol
MCP [5] defines a JSON-RPC 2.0 transport between an LLM host (the IDE or CLI) and one or more tool servers. Each server advertises a set of tools, each with a JSON Schema input definition [10]. The host serialises the agent’s tool call, forwards it over stdio or SSE, and returns the server’s JSON response as the next context message. MCP deliberately does not prescribe how the server implements a tool; this paper exploits that freedom to interpose durability guarantees on the write path.
Contribution. We present Resilient Write, an MCP server that addresses each of these failure modes with a dedicated, orthogonal layer (Table 1). The design follows three principles: (i) fail transparently—every rejection returns a machine-readable envelope; (ii) never 2.3 Failure Modes of Agent Writes overwrite in place—all writes go through a temp-file, fsync, verify, atomic-rename pipeline; Agent writes can fail at several points in the (iii) each layer is independently adoptable— stack: an agent can use only rw.safe_write and • Content filtering. Host-side or API-side rw.handoff_write without ever touching the safety classifiers may reject payloads that scratchpad or chunker. contain token-shaped strings, even when the The remainder of this paper is organised as tokens are redacted or fictitious [11]. follows. Section 2 reviews the relevant context. • Truncation. Large payloads may be Section 3 describes the six-layer architecture and silently clipped by transport limits, shell three extension tools. Section 4 covers implebuffer sizes, or context-window overflow. mentation details. Section 5 reports on the test • Atomicity. A naive open / write / close suite, a case study, and a quantitative comparisequence leaves a partially-written file on son against baselines. Section 6 surveys related crash. The POSIX rename() call [12] is the work. Section 7 discusses design tradeoffs, agent standard remedy, but few agent tool impleadoption, and limitations, and Section 8 conmentations use it. cludes. • Session loss. If the agent process or the underlying LLM call is interrupted, in-flight state—the current draft, the plan, the list 2 Background of completed steps—is lost unless explicitly persisted. 2.1 LLM Coding Agents These are not hypothetical: the motivating inA growing class of developer tools embed an cident (Section 1) exercised all four within a sinLLM in an edit–test–commit loop. Claude gle twenty-minute session. 2
• github_pat (w = 0.35): GitHub finegrained and classic PATs (ghp_, gho_, etc.). • jwt (w = 0.25): The three-segment base64 eyJ structure. • pem_block (w = 0.50): ––-BEGIN * PRIVATE KEY––- blocks. • aws_secret (w = 0.40): Context-sensitive match requiring a key name followed by a 40-character base64 value. • pii (w = 0.15): Email addresses, SSNs, phone numbers (conservative patterns to limit false positives). • binary_hint (w = 0.20): Long base64 blobs (> 200 chars) or dense non-printable byte sequences.
LLM Coding Agent tool call
MCP Transport (stdio / SSE)
L3 Error Envelopes
L0 Risk Score classify
errors
L1 Safe Write (atomic R/W)
L2 Chunk Compose
L4 Scratchpad (OOB) OOB
L5 Handoff (HANDOFF.md) Filesystem
.resilient_write/ + workspace
Scoring function. Let F be the set of families with at least one match, let wf be the weight of family f , and let nf be the number of distinct matches in family f . The raw score (Equation 1) is:
Figure 1: Six-layer architecture of Resilient Write. Arrows show data flow from the agent’s tool call through each layer to the filesystem. L3 error envelopes (orange) are cross-cutting; L4 scratchpad (green) writes out-of-band.
3
s=
wf · min 1.5, 1.0 + 0.25 (nf − 1)
(1)
f ∈F
Architecture
The inner term provides sub-linear damping: a second match in the same family adds only 25% of the base weight, and contributions saturate at 1.5×. Size heuristics add fixed increments (e.g., +0.15 for files over 100 KB, +0.20 for lines exceeding 2 000 characters). The final score is clamped to [0, 1].
Resilient Write is structured as six orthogonal layers, each targeting a specific failure mode. Table 1 summarises the mapping and Figure 1 shows the data flow. Layers can be adopted independently; the minimum useful deployment is L1 + L5.
3.1
X
Verdicts. The score maps to a categorical verdict: high ≥ 0.70, medium ≥ 0.40, low ≥ 0.10, otherwise safe. The verdict, the score, a list of detected patterns (each truncated to 16 characters to avoid leaking the matched secret), and a set of suggested actions are returned in a structured JSON response.
L0: Pre-flight Risk Scoring
Before content reaches the filesystem, rw.risk_score runs a deterministic classifier over the draft. The classifier is a pure function: no LLM call, no network access, bounded at under 50 ms on 100 KB inputs.
Workspace policy overrides. A perworkspace file .resilient_write/policy.yaml allows operators to extend or disable pattern families, adjust verdict thresholds, and set the global retry budget. This mechanism lets a security-testing workspace suppress false positives without weakening defaults for other projects.
Pattern families. The classifier maintains a taxonomy of seven pattern families, each with a numeric weight reflecting the likelihood that the pattern will trigger a downstream content filter: • api_key (w = 0.35): Anthropic, OpenAI, AWS access key ID, Datadog, and generic bearer-token patterns. 3
Table 1: The six layers of Resilient Write and the failure modes they address. Layer
MCP Tool
Mechanism
Failure Mode Addressed
L0 L1 L2 L3 L4 L5
rw.risk_score rw.safe_write rw.chunk_* (error envelope) rw.scratch_* rw.handoff_*
Deterministic regex + size classifier Temp file, fsync, hash verify, atomic rename Numbered chunk files with contiguity check Typed JSON error schema Content-addressed out-of-band store YAML+Markdown envelope with hash audit
Silent content-filter rejection Truncation, corruption, half-writes Payload too large for single call Opaque, unstructured error signals Secrets that must not enter the tree Cross-session continuity loss
3.2
tools: • rw.chunk_write persists one chunk to a session directory (e.g., part-001.txt) via safe_write, making retries idempotent. • rw.chunk_append auto-increments the chunk index, removing an entire class of off-by-one errors. • rw.chunk_compose concatenates all chunks in index order, verifying contiguity (no gaps) and reconciling against the manifest’s total_expected count before writing the final file through safe_write. Each chunk is individually journaled and hashverified, so if chunk 5 of 8 fails, chunks 1–4 are already durable on disk. Only the failing chunk needs to be retried.
L1: Transactional Atomic Writes
The rw.safe_write tool implements a fourphase write protocol: 1. Precondition check. Three modes are supported: create (reject if target exists), overwrite (unconditional), and append (concatenate to existing content). An optional expected_prev_sha256 field enables optimistic concurrency control: if the current file’s hash does not match, the write is rejected with a stale_precondition error. 2. Exclusive temp-file write. Content is written to a temporary file opened with O_CREAT | O_EXCL, followed by fsync(). 3. Read-back hash verification. The temp file is re-read and its SHA-256 is compared against the expected hash of the input bytes. A mismatch raises write_corruption and 3.4 L3: Typed Error Envelopes the temp file is deleted. Every failure across L1–L5 returns a uniform 4. Atomic rename. os.replace() moves JSON envelope (Listing 1): the temp file over the target, guaranteeing Listing 1: L3 error envelope (abbreviated). that the file is either fully replaced or untouched. { "ok": false, On success, a journal row is appended "error": "blocked", to .resilient_write/journal.jsonl record"reason_hint": "content_filter", ing the timestamp, path, SHA-256, byte count, "detected_patterns": ["api_key"], "suggested_action": "redact", mode, and caller identity. The journal is append"retry_budget": 2, only .jsonl by design: no SQL database, no mi"context": { "score": 0.82 } gration burden, and each row is independently } grep-able. The error field is one of five kinds: blocked (content filter or policy), stale_precondition 3.3 L2: Resumable Chunked Compo(concurrency violation), write_corruption sition (hash mismatch), quota_exceeded (disk full or Large or risky writes can be decomposed into cap), and policy_violation (permissions or numbered chunks. The protocol exposes three path traversal). 4
The reason_hint categorises the underlying cause: content_filter, size_limit, encoding, permission, network, or unknown. Crucially, content_filter is not marked retriable, preventing the infinite-retry loop that motivated this project. The retry_budget field is a per-response integer that decrements on identical retries. When it reaches zero, the tool refuses further attempts, forcing the agent to change strategy. Because the budget is embedded in the response (not tracked server-side), it is stateless and transparent.
blocked on L0 due to raw key prefixes. next_steps: - Redact sk-ant-* tokens to {REDACTED}. - Retry chunk 4 via rw.chunk_write. last_good_state: - path: report.tex sha256: 4b0c12ea... ---
The last_good_state field records per-file SHA-256 hashes. On read, rw.handoff_read performs a drift check: each listed file is rehashed and compared against the recorded digest. Mismatches produce warnings (not errors), allowing the new agent to proceed while 3.5 L4: Content-Addressed Scratch- remaining aware that on-disk state has dipad verged. Previous envelopes are optionally archived to .resilient_write/handoffs/ with Some content—raw credentials captured from timestamps, preserving a history of handoff live traffic, PII in test fixtures, binary blobs— points. legitimately does not belong in the workspace tree. rw.scratch_put writes such material to .resilient_write/scratch/<sha256>.bin, 3.7 Extensions: Preview, Validation, and Analytics keyed by content hash. Identical payloads are automatically deduplicated; an append-only Three additional tools emerged from practical index.jsonl records metadata (label, times- use of the system during the preparation of this tamp, content type) for each deposit. paper itself. rw.scratch_ref looks up metadata without retrieving content, and rw.scratch_get Chunk preview. rw.chunk_preview perreturns the raw bytes. The latter is gated forms a dry-run compose: it concatenates all by the RW_SCRATCH_DISABLE_GET environment chunks in a session, verifies contiguity and variable: when set, the scratchpad becomes total_expected, and returns the content string write-only, enabling a “deposit box” pattern suit- without writing to disk. During this paper’s able for high-sensitivity workspaces. composition, a stale chunk session from a prior
attempt collided with new chunks, producing a file with a duplicate preamble. Preview would When a task is interrupted—by a content-filter have caught this before the faulty compose. block, context-window exhaustion, or process validation. rw.validate crash—a fresh agent must re-derive the task’s Format-aware context from first principles. rw.handoff_write provides syntax checking for common forA serialises a structured envelope to HANDOFF.md mats: L TEX (brace balancing, environment matching, \documentclass presence), JSON (Listing 2): (json.loads), Python (ast.parse), and YAML Listing 2: HANDOFF.md front-matter (abbre- (yaml.safe_load). The validator is a pure funcviated). tion returning a structured diagnostic envelope: --{valid, format, errors[{line, message, task_id: telemetry-report severity}]}. During this paper’s composition, status: partial a missing macro definition (\layer) caused a agent: claude-opus-4-6 build failure that this validator’s LATEX checker summary: | would have flagged at preview time. 19-page report complete; appendix
3.6
L5: Task-Continuity Handoff
5
since it is derived state—a fresh agent can reconstruct the manifest by enumerating chunk files on disk via rw.chunk_status. This design treats the chunk files as the source of truth and the manifest as a convenience cache.
Journal analytics. rw.analytics analyses the append-only journal to report write counts, timing, hot paths, chunk-session summaries, and write velocity. This enables agents (and operators) to understand write patterns and diagnose performance issues without parsing raw .jsonl.
4.4
4
When L0 detects a sensitive pattern, the match snippet included in the response is truncated to 16 characters. This is a deliberate informationcontrol measure: the classifier’s output must not itself become a vector for leaking the secret it detected. The truncated prefix is sufficient for the agent to locate the match in its own draft and apply a targeted redaction.
Implementation
Resilient Write is implemented in Python 3.12 as an MCP server that communicates over stdio. The server registers sixteen tools (Table 1 plus inspection and extension tools such as rw.chunk_status, rw.validate, rw.analytics, and rw.journal_tail) and relies on no external services or databases.
4.5 4.1
Risk-Score Snippet Truncation
Workspace Root Safety
Scratchpad Deduplication
The scratchpad uses SHA-256 content addressing. If the agent deposits the same payload twice (e.g., the same API key observed in two separate HTTP captures), only one .bin file is stored. Metadata entries in index.jsonl accumulate independently, allowing multiple labels to alias the same underlying content. On read-back, the content is re-hashed to detect manual edits to the .bin file since deposit time.
The server resolves its workspace root at startup from the RW_WORKSPACE environment variable or the current working directory. A hard-coded deny-list of unsafe roots (/, /etc, /usr, /tmp, etc.) prevents accidents when the variable is unset or mis-expanded. All user-supplied paths are resolved and checked to ensure they do not escape the workspace via .. traversal or symlink resolution, following standard OWASP path-traversal mitigations [13].
5
Evaluation
We evaluate Resilient Write along three axes: (1) correctness, via an automated test suite; The audit journal is an append-only .jsonl (2) practical utility, via a case study; and file. Each row is a single JSON object with (3) quantitative comparison against baseline apsorted keys, making the file both diff-friendly proaches. and grep-friendly. POSIX O_APPEND semantics guarantee atomic single-writer appends without 5.1 Test Suite explicit locking. The journal records only metadata (path, hash, byte count, mode); file content The test suite comprises 186 tests across twelve is never duplicated into the log. modules, exercising every layer, every error path, and all three extension tools. Table 2 summarises coverage by component. 4.3 Chunk Manifest Consistency Figure 2 visualises the distribution. The 42 Chunk sessions maintain a manifest JSON extension tests cover format validation (15 tests file recording created_at, updated_at, and for LATEX, JSON, Python, and YAML syntax total_expected. The manifest is written atom- checking), journal analytics (10 tests), and chunk ically (temp + rename) but is not journaled, preview (5 tests), plus auto-detection and edge
4.2
Journal Design
6
Table 3: Comparison of the original failed session and the Resilient Write replay.
Table 2: Test distribution by component. Layer
Module(s)
Tests
L0 L1 L2 L3 L4 L5 Ext. Infra
test_risk_score test_safe_write, test_journal test_chunks test_errors test_scratchpad test_handoff test_new_features test_server, test_scaffold, test_stdio Total
Metric
28 17 27 27 21 8 42 16
Write attempts Content lost Structured error Agent self-corrected Manual intervention
With Resilient Write
6 yes no no yes
2 no yes yes no
186
5.2
New Features
8.6% (16)
22.6% (42)
4.3% (8)
15.1% (28)
11.3% (21)
L5 Handoff
L4 Scratchpad
9.1% (17)
L1 Safe Write 14.5% (27)
Case Study: Telemetry Report
The motivating incident (Section 1) was replayed with Resilient Write interposed. Table 3 compares the two runs. In the replay, the agent called rw.risk_score before the first write attempt, received a high verdict with api_key detected, and applied a targeted redaction. The subsequent rw.safe_write succeeded on the first attempt. No heredoc workaround was needed, no tokens were wasted on blind retries, and the journal preserved a complete audit trail.
Infrastructure
L0 Risk Score
Original
14.5% (27)
L3 Errors L2 Chunks
5.3
Quantitative Comparison
Table 4 compares three approaches to agent file Figure 2: Test distribution across layers and exI/O across four key metrics. Recovery time and tensions (186 tests total). wasted-call rates were measured during development; data-loss probability and self-correction rates are estimates informed by an indepencases. All tests use synthetic but shaped credendent severity analysis performed by a local LLM tials to exercise real regex match paths without (Gemma 3, prompted to rank each failure mode’s embedding secrets in test code. impact on agent productivity). Figure 3 visualises these differences. The Chunk contiguity. Dedicated tests verify Naive baseline is a direct open/write/close that rw.chunk_compose rejects sessions with with try/except; the Defensive baseline adds non-contiguous indices (e.g., chunks 1, 3 with temp-file + atomic-rename but no pre-flight scorchunk 2 missing) and sessions whose chunk count ing or structured errors. Resilient Write’s does not match the manifest’s total_expected.
Table 4: Estimated metrics across three write approaches.
Concurrency guards. The expected_prev_sha256 optimistic lock is tested by writing a file, computing its hash, mutating the file externally, and confirming that a subsequent safe_write with the stale hash returns stale_precondition. 7
Metric
Naive
Defensive
Resilient Write
Recovery time (s) Data loss prob. (%) Self-correction (%) Wasted calls (%)
10.0 5.0 5 25
5.5 1.0 15 12.5
2.0 0.1 65 3.0
6
Naive Defensive Resilient-Write
60
Related Work
50
Metric value
Transactional file systems. The atomic temp-file–fsync–rename pattern used by L1 is 30 well-established in systems literature. Gray’s 20 transaction concept [14] formalised the ACID 10 properties that underpin our journal design. 0 Recovery time Data loss Self-correction Wasted tool Hagmann [15] demonstrated logging and group (seconds) prob. (%) rate (%) calls (%) commit in the Cedar file system, and NightinFigure 3: Comparison of write approaches across gale et al. [16] showed that relaxing synchrony four metrics. Lower is better for recovery time, constraints can improve throughput without sacdata loss, and wasted calls; higher is better for rificing durability. Resilient Write applies self-correction rate. these ideas at the tool-call granularity rather than the kernel level, trading generality for deployment simplicity. 40
Content filter
1.0
0.5
0.0
0.5
0.0
0.0
Truncation
0.0
1.0
0.5
0.5
0.0
0.0
Partial write
0.0
1.0
0.5
0.0
0.0
0.0
Retry thrashing
0.5
0.0
0.0
1.0
0.0
0.0
Opaque errors
0.0
0.0
0.0
1.0
0.0
0.0
Session loss
0.0
0.0
0.5
0.0
0.0
1.0
Secret leakage
1.0
0.0
0.0
0.0
1.0
0.0
Handoff failure
0.0
0.0
0.0
0.0
0.0
1.0
L0 L1 Risk Score Safe Write
Concurrency control. The expected_prev_sha256 guard in L1 is a form of optimistic concurrency control [17] adapted for agent–file interactions. Unlike database-level OCC, our scheme requires no version counter or timestamp oracle: the content hash itself serves as the version identifier.
L2 L3 L4 L5 Chunks Typed ErrorsScratchpad Handoff
Agent error handling. SWE-agent [9] introduced the concept of an agent–computer interface (ACI) that mediates between the LLM and the operating system, but its error model remains unstructured text. SWE-bench [8] evaluates agent success rates but does not isolate write-path failures as a distinct cause of task layered approach yields a 5× reduction in re- failure. To our knowledge, Resilient Write covery time, a 50× reduction in data loss prob- is the first system to provide a typed error enveability, and a 13× improvement in agent self- lope designed specifically for autonomous agent correction rate. consumption. Figure 4: Failure mode coverage by architecture layer. Darker cells indicate primary mitigation (1.0); lighter cells indicate secondary mitigation (0.5).
5.4
Failure Mode Coverage
Secret detection. Tools such as truffleHog, detect-secrets, and GitHub’s push-protection scanner perform post-hoc secret scanning on committed content. L0’s risk scorer operates pre-flight—before the content reaches the filesystem—and is tuned not for audit completeness but for predicting whether a downstream content filter will reject the payload. This is a complementary, not competing, concern.
Figure 4 maps eight observed failure modes to the six architecture layers. Each cell indicates whether the layer provides primary (1.0) or secondary (0.5) mitigation for the failure mode. The heatmap confirms that the layers are largely orthogonal: no single layer addresses more than three failure modes, and every failure mode is addressed by at least one layer. 8
7
Discussion
7.1
Design Tradeoffs
rw.* tools over raw Write/Edit operations. The file specifies a decision table mapping task types (create, append, large file, sensitive content) to the appropriate rw.* tool and documents the chunked-writing protocol. This approach is portable: analogous files exist for Cursor (.cursorrules), Codex (codex.md), and Copilot (.github/copilot-instructions.md). The key insight is that agent instruction files are the natural integration surface for MCP tool preferences—no code changes to the agent itself are required.
Plain-text journals vs. SQL. We chose append-only .jsonl over SQLite for the audit journal. This sacrifices indexed queries but gains human readability, diff-ability in version control, and zero external dependencies. For the expected journal sizes (tens to low hundreds of rows per session), linear scan is acceptable.
Unencrypted scratchpad. The scratchpad stores sensitive material as plaintext .bin files, delegating encryption to filesystem-level mechanisms (FileVault, LUKS). This is a deliberate separation of concerns: cryptographic key man- 7.3 Limitations agement is a solved problem at the OS layer, and • Single-workspace scope. The server re-implementing it in a tool server would introis bound to one workspace root per produce complexity and a false sense of security. cess. Multi-workspace orchestration would require external process management. Retry budget: per-response, not per• No cross-file transactions. If an agent session. The retry_budget integer is embedwrites files A, B, C in sequence and crashes ded in each error response rather than tracked between B and C, there is no write-ahead server-side. This keeps the server stateless at log to roll the workspace back to a consistent the cost of losing budget context across agent state. Each file write is individually atomic, restarts. In practice, the purpose of the budget but the set of writes is not. is to halt loops within a single agent invocation; • No distributed coordination. The joura fresh agent legitimately starts with a fresh budnal and scratchpad are local. Synchronising get. state across agents on different machines is out of scope. • Classifier coverage. L0 targets the most Drift warnings, not errors. L5’s drift check common content-filter triggers observed in on last_good_state hashes produces warnings practice. Novel secret formats or nonrather than hard failures. A file may have English PII patterns require policy-file exbeen intentionally edited between sessions (by tensions. the user or a prior agent), and blocking resumption on benign drift would be counterproductive. The warning is surfaced so the agent can decide 7.4 Future Directions whether to trust or re-derive the changed file.
7.2
Cross-file write-ahead logging would enable true workspace-level transactions. Integrating L0 with a lightweight embedding model could improve recall on obfuscated secrets without sacrificing the latency budget. The handoff envelope (L5) could be extended with a machinereadable dependency graph, enabling orchestrators to schedule resumption tasks automatically.
Agent Awareness and Adoption
A tool server is only useful if agents actually invoke it. MCP tool registration makes the tools available, but does not make them preferred. We address this through a CLAUDE.md convention file (read automatically by Claude Code at session start) that instructs the agent to prefer 9
8
[4] GitHub, “GitHub copilot.” https: //github.com/features/copilot, 2024. Accessed: 2026-04-12.
Conclusion
We have presented Resilient Write, a sixlayer MCP server that transforms the fragile write path of autonomous coding agents [5] Anthropic, “Model context protocol specification.” https://modelcontextprotocol. into a durable, auditable, and recoverable opio/specification, 2024. Accessed: 2026eration. Each layer targets a specific, ob04-12. served failure mode: pre-flight risk scoring (L0) prevents content-filter rejections; transactional [6] J. Lux Ferro, “What leaves your workstawrites (L1) eliminate truncation and corruption when you use an LLM coding CLI.” tion; chunked composition (L2) enables inhttps://sperixlabs.org/post/2026/04/ cremental progress on large files; typed error what-leaves-your-workstation-whenenvelopes (L3) give agents structured signals you-use-an-llm-coding-cli/, 2026. to reason about; content-addressed scratchpad Blog post. Accessed: 2026-04-12. storage (L4) keeps sensitive material out of the workspace tree; and handoff envelopes (L5) pre- [7] sst, “OpenCode: Terminal-native AI serve task context across sessions. coding agent.” https://github.com/sst/ Three extension tools—chunk preview, opencode, 2025. Accessed: 2026-04-12. format-aware validation, and journal analytics— emerged from using the system to compose this [8] C. E. Jimenez, J. Yang, A. Wettig, S. Yao, K. Pei, O. Press, and K. Narasimhan, paper itself, demonstrating that practical use “SWE-bench: Can language models resolve surfaces requirements that design-time analysis real-world GitHub issues?,” 2024. misses. The layers are orthogonal and independently [9] J. Yang, C. E. Jimenez, A. Wettig, K. Liber, adoptable, requiring no changes to existing agent S. Yao, K. Narasimhan, and O. Press, code beyond MCP tool registration and an op“SWE-agent: Agent-computer interfaces tional instruction file (CLAUDE.md). A 186-test enable automated software engineering,” suite validates correctness at each layer, and 2024. quantitative comparison against naive and defensive baselines shows a 5× reduction in recovery [10] A. Wright, H. Andrews, B. Hutton, and time, 50× reduction in data loss probability, and G. Dennis, “JSON schema: A media type 13× improvement in agent self-correction rate. for describing JSON documents.” https:// Resilient Write is open-source under json-schema.org/specification, 2020. the MIT license at https://github.com/ Draft 2020-12. sperixlabs/resilient-write. [11] N. Pilkington et al., “Leaking secrets through LLM agents: Risks of toolReferences augmented language models,” in Workshop on Foundation Models and Cybersecurity [1] Anthropic, “Claude code: An agentic cod(FMCS), 2023. ing tool.” https://docs.anthropic.com/ en/docs/claude-code, 2025. Accessed: [12] IEEE and The Open Group, “The 2026-04-12. open group base specifications issue [2] OpenAI, “Codex CLI: Open-source coding agent.” https://github.com/openai/ codex, 2025. Accessed: 2026-04-12. [3] Anysphere Inc., “Cursor: The AI code editor.” https://cursor.com, 2024. Accessed: 2026-04-12. 10
7, 2018 edition: rename().” https: //pubs.opengroup.org/onlinepubs/ 9699919799/functions/rename.html, 2017. Accessed: 2026-04-12.
[13] OWASP Foundation, “OWASP top 10 – [16] E. B. Nightingale, V. Kaushik, P. M. Chen, and J. Flinn, “Rethink the sync,” in Pro2021.” https://owasp.org/Top10/, 2021. ceedings of the 7th USENIX Symposium on Accessed: 2026-04-12. Operating Systems Design and Implementa[14] J. Gray, “The transaction concept: Virtues tion (OSDI), pp. 1–14, 2006. and limitations,” in Proceedings of the 7th International Conference on Very Large [17] P. A. Bernstein, V. Hadzilacos, and Data Bases (VLDB), pp. 144–154, 1981. N. Goodman, “Concurrency control and recovery in database systems,” Addison[15] R. Hagmann, “Reimplementing the Cedar Wesley, 1987. file system using logging and group commit,” in Proceedings of the 11th ACM Symposium on Operating Systems Principles (SOSP), pp. 155–162, 1987.
11