fix(memory): reject absolute filesystem paths with corrective routing

[G7CNF]

Summary

Fixes a local UX failure mode where absolute filesystem paths (for example /Users/.../file.md) are incorrectly routed to memory tools and treated as missing workspace-memory docs.

Repro (before)

User asks:

• open the following in the default editor: '/Users/.../issue-12055-comment-draft.md'

Observed behavior:

• agent attempts memory-path semantics and responds as if the file is missing from memory-backed workspace docs.

Root cause

memory_read and memory_write accepted path-like inputs without rejecting obvious filesystem path forms, so the model could misroute absolute paths into memory operations.

Fix

In src/tools/builtin/memory.rs:

• added looks_like_filesystem_path() classifier for:
  • Unix absolute paths (/Users/...)
  • Windows absolute paths (C:\..., D:/...)
  • home-shorthand (~/...)
• memory_read now rejects filesystem-looking paths early with actionable guidance:
  • use read_file for reads
  • use shell open "<absolute_path>" for default-editor open
• memory_write now rejects filesystem-looking targets with actionable guidance:
  • use write_file for filesystem writes
• strengthened tool descriptions to explicitly forbid absolute filesystem paths
• added focused unit tests for path classification

After

Absolute filesystem paths are explicitly redirected away from memory tools with corrective messaging, reducing memory-vs-filesystem routing confusion.

Validation

• cargo test -p ironclaw path_routing_tests -- --nocapture
  • Result: 2 passed, 0 failed
• runtime smoke check:
  • ~/.local/ironclaw/bin/ironclaw service status => running/loaded

[gemini-code-assist]

Summary of Changes

Hello, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request addresses a user experience issue where absolute filesystem paths were incorrectly routed to memory tools, leading to confusion and failed operations. By introducing robust path validation and clearer guidance, the system now intelligently distinguishes between workspace-memory paths and local filesystem paths, ensuring that users are directed to the appropriate tools for their intended actions and preventing misinterpretation of commands.

Highlights

• Path Classification: Introduced a new utility function, looks_like_filesystem_path(), to accurately identify absolute Unix, Windows, and home-shorthand filesystem paths.
• Memory Tool Validation: Implemented early rejection logic in both memory_read and memory_write tools to prevent them from processing inputs that resemble local filesystem paths, providing actionable guidance to the user.
• Improved Tool Descriptions: Updated the descriptions for memory_read and memory_write to explicitly warn against using absolute filesystem paths and clarify their intended use for workspace-memory paths.
• Unit Testing: Added focused unit tests to validate the correct classification of filesystem paths by the new looks_like_filesystem_path() function.

Changelog

• src/tools/builtin/memory.rs
  • Imported std::path::Path for path manipulation capabilities.
  • Added the looks_like_filesystem_path function to detect common absolute filesystem path patterns.
  • Modified the MemoryWriteTool description to explicitly forbid absolute filesystem paths.
  • Implemented validation within MemoryWriteTool::call to reject filesystem-like targets and provide corrective instructions.
  • Updated the MemoryReadTool description to warn against using absolute filesystem paths.
  • Added validation to MemoryReadTool::call to prevent reading filesystem paths and suggest read_file or shell open.

Ignored Files

• Ignored by pattern: .github/workflows/** (1)
  • .github/workflows/staging-ci.yml

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[zmanian]

Review: fix(memory): reject absolute filesystem paths with corrective routing

Verdict: APPROVE

Clean fix for a real UX problem where the LLM misroutes filesystem paths into memory tool calls.

Correctness

looks_like_filesystem_path() correctly detects:

• Unix absolute paths (/Users/...)
• Windows absolute paths (C:\..., D:/...)
• Home shorthand (~/...)

The implementation using Path::new(path).is_absolute() for Unix paths and manual byte checking for Windows drive letters is correct. The is_absolute() call handles edge cases like //network paths on Unix.

Error messages

The error messages are actionable -- they tell the user to use read_file/write_file instead, and suggest shell open for editor opens. This is exactly the corrective guidance that helps the LLM self-correct on retry.

Tool descriptions

Updated descriptions now explicitly say "Never pass absolute filesystem paths" -- good for steering LLM tool selection upstream.

Tests

Two focused tests cover the happy paths. Could add an edge case for empty string and relative paths with .. components, but those are workspace-valid paths so the current behavior (allow) is correct.

No issues found.

[zmanian]

Review: fix(memory): reject absolute filesystem paths with corrective routing

Verdict: Approve (already approved previously).

Clean fix for a real UX problem where the LLM misroutes filesystem paths into memory tool calls.

Correctness: looks_like_filesystem_path() correctly detects Unix absolute paths, Windows drive letters (C:\..., D:/...), and home shorthand (~/...). The Path::new(path).is_absolute() call handles edge cases like //network paths on Unix.

Error messages: Actionable -- they tell the user to use read_file/write_file instead, and suggest shell open for editor opens. Good for LLM self-correction on retry.

Tool descriptions: Updated to explicitly say "Never pass absolute filesystem paths" -- good for steering LLM tool selection upstream.

Tests: Two focused tests cover the happy paths. Relative paths with .. components are workspace-valid paths so the current behavior (allow) is correct.

Nit: The PR bundles an unrelated CI change (commit 1: use default_branch instead of hardcoded main in staging-ci.yml) with the memory fix (commit 2). These should ideally be separate PRs for clean revert paths, but since the CI change is low-risk and already green, not a blocker.

[zmanian]

LGTM. The security fix is sound:

• looks_like_filesystem_path() correctly detects Unix absolute paths (via Path::is_absolute()), home-dir expansion (~/), and Windows drive-letter paths (C:\, D:/).
• Both memory_write and memory_read reject filesystem paths early with a clear error message that redirects to the correct tools (write_file/read_file).
• Good test coverage for both positive (filesystem paths) and negative (workspace paths) cases.
• Error messages include corrective guidance, which is helpful for LLM tool callers.

Minor note: this PR also includes CI workflow changes (hardcoded main -> DEFAULT_BRANCH). That is unrelated to the security fix and ideally would be a separate commit/PR, but the CI changes themselves look correct.

No .unwrap() or .expect() in production code. Uses crate:: imports. Approved.