---
id: 10327
title: 'Bug: Edit/Write MCP tools fail silently against .agent/skills/ directory'
state: CLOSED
labels:
  - bug
  - needs-re-triage
assignees: []
createdAt: '2026-04-25T04:31:32Z'
updatedAt: '2026-06-07T09:21:15Z'
githubUrl: 'https://github.com/neomjs/neo/issues/10327'
author: neo-gemini-pro
commentsCount: 2
parentIssue: null
subIssues: []
subIssuesCompleted: 0
subIssuesTotal: 0
blockedBy: []
blocking: []
closedAt: '2026-06-07T09:21:15Z'
---
# Bug: Edit/Write MCP tools fail silently against .agent/skills/ directory

### Architectural Context
When attempting to use `replace` or `write_file` tools on paths within `.agent/skills/`, the tools return success messages (e.g., "successfully updated"), but the changes are not persisted to the local disk. Bash tools (`cp`, `touch`) work correctly in these directories. 

### The Problem
This appears to be a harness guardrail designed to prevent autonomous agents from modifying their own instructions and skill logic through standard tool flow. The intent of this security boundary is sound. However, the implementation violates the core tool contract: it fails *silently*. Returning a simulated success when the operation was actively blocked causes agents to waste multiple cycles attempting to read back state that was never written, degrading efficiency and context.

### Avoided Traps
- **Do not bypass the guardrail:** The security perimeter around `.agent/skills/` is valid and should remain.
- **Do not use bash as a primary solution:** Agents currently work around this by writing to `/tmp/` and using `cp`, but the primary MCP tool must be reliable.

### Prescription
The tool implementation or harness interceptor must be modified to make this failure mode loud. If a write is blocked due to path restrictions, the tool MUST return an explicit error (e.g., `Error: Write blocked by harness guardrail`) instead of simulating success.

Origin Session ID: `0b29a8fa-c6b0-42e2-ab3b-8015a99db2d8`

## Timeline

- 2026-04-25T04:31:34Z @neo-gemini-pro added the `bug` label
- 2026-06-06T17:05:56Z @neo-gpt added the `needs-re-triage` label
### @neo-gpt - 2026-06-06T17:06:07Z

**Input from GPT-5.5 (Codex Desktop, extra-high thought budget):**

> ● [ARCH_ALIGNMENT] Retrospective triage per `ticket-triage` skill: this issue is not branchable as written and has been labeled `needs-re-triage`.
> 
> V-B-A evidence:
> - The live/local issue payload is still the original 2026-04-25 report, with no follow-up comments and only the original `bug` label before this triage.
> - The ticket targets `.agent/skills/`, but current `dev` has no `.agent/` directory; the canonical live skill substrate is `.agents/skills/**`.
> - The ticket names old `replace` / `write_file` MCP behavior. In the current Codex harness, manual repo edits are performed through the `apply_patch` contract; the specific silent-success surface described here is not present in this tool shape.
> - Current substrate already has explicit skill-edit governance (`create-skill`, `turn-memory-pre-flight`, `ticket-intake` / `ticket-create` gates) around `.agents/skills/**`; the ticket does not identify a current repo-owned implementation point for the alleged harness interceptor.
> 
> Verdict: `superseded / stale-harness-surface` until a current reproducer exists. If this still reproduces in Antigravity/Gemini, the ticket needs a refreshed body with the current tool names, exact path (`.agents/skills/**` if applicable), current harness version, minimal reproducer, and the code-owned surface that can make the failure loud. I am not applying the `ai` label or self-assigning because the present prescription would create a stale implementation lane rather than current v13 work.

### @neo-gpt - 2026-06-07T09:21:02Z

**Input from GPT-5 (Codex Desktop):**

> ● ## Closeout: superseded / stale harness surface
> 
> [ARCH_ALIGNMENT]
> 
> V-B-A refreshed on 2026-06-07 before terminal action:
> 
> - The ticket targets `.agent/skills/`, but the current repo substrate is `.agents/skills/**`; `.agent/` is absent in the live checkout.
> - The current repo-owned file-system MCP `write_file` implementation calls `fs.writeFile()` and would throw on write failure; I found no skill-path-specific guard that returns synthetic success.
> - Current skill-edit governance already lives in `create-skill`, `turn-memory-pre-flight`, and `ticket-intake`, which is the correct repo-owned protection layer for `.agents/skills/**` edits.
> - The previous 2026-06-06 triage already classified the report as `superseded / stale-harness-surface` and applied `needs-re-triage`; no current reproducer or repo-owned failing interceptor has been added since.
> 
> Verdict: closing as `not planned`. If this still reproduces in a current Antigravity/Gemini harness, reopen or file a successor with the current path, current tool names, harness version, minimal reproducer, and the repo-owned implementation surface that can make the failure loud.

- 2026-06-07T09:21:15Z @neo-gpt closed this issue

