# ACP file-system methods

## Metadata

| Field | Value |
|---|---|
| Institute | Molodetz Institute — Research & Retrieval Division |
| Subject | cap-protocol |
| Document type | Source Dossier |
| Tier | 1 |
| Source title | ACP File System |
| Source URL | https://agentclientprotocol.com/protocol/v1/file-system.md |
| Source type | specification |
| Source date (published) | Unknown, not stated (living docs) |
| Date researched | 2026-10-18 |
| Researched by | tai (agent), model: Muse Spark, on behalf of retoor |
| Research method | direct page fetch, method inventory via grep plus surrounding prose (capability gating, read/write shapes) |
| Confidence | High |
| Status | Active |

## Summary

Two client-hosted methods: `fs/read_text_file` (path + optional line/limit, returns content) and `fs/write_text_file` (path + content), both capability-gated per method; agents MUST NOT call unadvertised methods. No list/exists/delete, confirming the coding profile's `_cap/<rpc>` extension gap.

## Key findings

- Read supports line/limit windowing, which CAP's `cap.fs.read` lacks; the bridge must either emulate (read-all then slice) or pass through as an extension param.
- Absolute paths required, matching CAP's fs contract; unsaved-editor-state access is the rationale (N/A to tai, which reads disk).
- Per-method capability flags give tai's driver a truthful advertisement surface (offer read/write only when the coding profile grants them).

## Pros / strengths

- Minimal surface with strict gating: exactly the two methods a code agent needs most.

## Cons / limitations / caveats

- Inventory-level reading (grep + prose); error shapes and write atomicity unspecified in what was read.
- No list/exists/delete forces the `_cap` extension path for full coding-profile parity.

## Relevance to tai

Confirms the §9 bridge table: fs.read/write map natively, the rest need `_cap` extensions the driver must implement.

## Changelog

| Date | Change |
|---|---|
| 2026-10-18 | Initial dossier created. |