When gemini runs as an ACP agent and the host returns a file-system error from a delegated readTextFile call, AcpFileSystemService.normalizeFileSystemError (packages/cli/src/acp/acpFileSystemService.ts) decides whether the error means "file not found" by substring-matching the human-readable message against four exact phrases: The structured JSON-RPC code field on the error response (-32002 = RESOURCE_NOT_FOUND per the ACP spec) is ignored. Common phrasings produced by ACP hosts that don't match any of those four substrings — for example not_found: file not found, no such file or directory, or file_not_found — are classified as generic file-system errors instead of ENOENT. The user-visible symptom: write_file on a new path internally calls readTextFile first to check whether the file exists. When the read returns a not-found error that fails the substring check, the write tool sees a generic FS error rather than the expected ENOENT, treats the path as "exists but unreadable", and either retries or reports an opaque failure. From outside, the agent reasoning loop appears to hallucinate success after several retries because no write actually lands. This was discovered wiring gemini --experimental-acp into a custom ACP host. When the host's read errors carried message not_found: file not found and code -32002, every write_file call on a non-existent path silently failed (multi-minute hangs, watchdog restarts). Reformatting the host's error message to include the literal substring ENOENT made every write start succeeding immediately — confirming the substring matcher is the load-bearing path. (Discovered while running gemini --experimental-acp against a custom ACP host implementing fs.readTextFile / fs.writeTextFile delegation. The bug reproduces against any host whose not-found error message doesn't contain one of the four hardcoded substrings.)

• Reproduces on every write_file call to a non-existent path when the host's not-found error doesn't match one of the four hardcoded substrings.
• PR #26439 addresses this by checking error.code === -32002 first and expanding the substring set.

TL;DR

The issue can be fixed by modifying the AcpFileSystemService.normalizeFileSystemError function to prioritize checking the JSON-RPC code field for -32002 and expanding the substring matching for human-readable not-found error messages.

Guidance

• Inspect the JSON-RPC code field first and return ENOENT for -32002 (RESOURCE_NOT_FOUND) regardless of message phrasing.
• Expand the substring matching to recognize broader human-readable not-found phrasings, such as no such file, file_not_found, not_found, and cannot find.
• Consider applying the changes proposed in PR #26439, which addresses this issue by checking error.code === -32002 first and expanding the substring set.
• Verify the fix by testing write_file calls on non-existent paths with different error message phrasings from the ACP host.

Example

if (error.code === -32002) {
  return 'ENOENT';
} else if (
  errorMessage.includes('Resource not found') ||
  errorMessage.includes('ENOENT') ||
  errorMessage.includes('does not exist') ||
  errorMessage.includes('No such file') ||
  errorMessage.includes('no such file') ||
  errorMessage.includes('file_not_found') ||
  errorMessage.includes('not_found') ||
  errorMessage.includes('cannot find')
) {
  return 'ENOENT';
}

Notes

The proposed fix assumes that the ACP host returns a JSON-RPC code field with a value of -32002 for RESOURCE_NOT_FOUND errors. If this is not the case, additional modifications may be necessary.

Recommendation

Apply the workaround by modifying the AcpFileSystemService.normalizeFileSystemError function to prioritize checking the JSON-RPC code field and expanding the substring matching, as proposed in PR #26439. This should fix the issue and allow write_file calls to succeed as