feat(core): support nested directories in Plan Mode#27464
feat(core): support nested directories in Plan Mode#27464mahimashanware wants to merge 5 commits into
Conversation
|
Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). View this failed invocation of the CLA check for more information. For the most up to date status, view the checks section at the bottom of the pull request. |
🛑 Action Required: Evaluation ApprovalSteering changes have been detected in this PR. To prevent regressions, a maintainer must approve the evaluation run before this PR can be merged. Maintainers:
Once approved, the evaluation results will be posted here automatically. |
Summary of ChangesHello, I'm Gemini Code Assist1! 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 enhances the Plan Mode functionality by enabling support for nested directory structures within the designated plans directory. It refines path resolution and validation logic to ensure that tools like 'write_file', 'edit', and 'exit_plan_mode' operate correctly with subdirectories. Additionally, it introduces a policy mapping safeguard to maintain the integrity of Plan Mode and includes a fix for a build script issue related to directory cleanup. Highlights
Using Gemini Code AssistThe 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
Customization To customize the 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 Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counterproductive. 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. Footnotes
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces support for nested directory structures and path normalization within the plans directory across several tools and utilities, including the policy scheduler, edit tool, write-file tool, and plan path utilities. However, two important issues were identified in the review: a critical path traversal vulnerability in planUtils.ts where fallback path resolution bypasses real-path validation for non-existent files, and a cross-platform compatibility issue in build_package.js caused by using the Unix-specific rm -rf command instead of Node's native fs.rmSync.
| // 1. Handle case where agent provided an absolute path | ||
| if (path.isAbsolute(normalizedPlanPath)) { | ||
| try { | ||
| const realResolved = resolveToRealPath(normalizedPlanPath); | ||
| if (isSubpath(realPlansDir, realResolved)) { | ||
| return normalizedPlanPath; | ||
| } | ||
| } catch { | ||
| // Fall through if resolveToRealPath fails | ||
| } | ||
| } | ||
|
|
||
| // 3. Handle default case where agent provided a path relative to the plans directory | ||
| const resolvedPath = path.resolve(plansDir, trimmedPath); | ||
| const realPath = resolveToRealPath(resolvedPath); | ||
| const realPlansDir = resolveToRealPath(plansDir); | ||
| // 2. Try resolving relative to project root | ||
| const resolvedFromProjectRoot = path.resolve(projectRoot, normalizedPlanPath); | ||
| try { | ||
| const realResolved = resolveToRealPath(resolvedFromProjectRoot); | ||
| if (isSubpath(realPlansDir, realResolved)) { | ||
| return resolvedFromProjectRoot; | ||
| } | ||
| } catch { | ||
| const directResolved = path.resolve(resolvedFromProjectRoot); | ||
| if (isSubpath(realPlansDir, directResolved)) { | ||
| return resolvedFromProjectRoot; | ||
| } | ||
| } | ||
|
|
||
| if (!isSubpath(realPlansDir, realPath)) { | ||
| throw new Error( | ||
| PlanErrorMessages.PATH_ACCESS_DENIED(trimmedPath, plansDir), | ||
| ); | ||
| // 3. Try resolving relative to plansDir | ||
| const resolvedFromPlansDir = path.resolve(plansDir, normalizedPlanPath); | ||
| try { | ||
| const realResolved = resolveToRealPath(resolvedFromPlansDir); | ||
| if (isSubpath(realPlansDir, realResolved)) { | ||
| return resolvedFromPlansDir; | ||
| } | ||
| } catch { | ||
| const directResolved = path.resolve(resolvedFromPlansDir); | ||
| if (isSubpath(realPlansDir, directResolved)) { | ||
| return resolvedFromPlansDir; | ||
| } | ||
| } |
There was a problem hiding this comment.
Security Vulnerability: Path Traversal / Arbitrary File Write
The fallback logic in the catch blocks uses isSubpath(realPlansDir, directResolved) where directResolved is resolved using path.resolve instead of resolveToRealPath.
If a file does not exist yet (which is always the case for new files being created), resolveToRealPath throws an error, causing the code to enter the catch block. If the path contains a symbolic link pointing to an outside directory (e.g., plans/symlink_to_outside/new_file.md), directResolved will textually start with realPlansDir, bypassing the subpath check. This allows an attacker or a compromised agent to write files to arbitrary locations on the filesystem.
To fix this, we should resolve the real path of the closest existing ancestor directory before performing the subpath check.
const getRealResolvedPath = (targetPath: string): string => {
let current = path.resolve(targetPath);
while (current && current !== path.dirname(current)) {
try {
const real = resolveToRealPath(current);
const relative = path.relative(current, targetPath);
return path.resolve(real, relative);
} catch {
current = path.dirname(current);
}
}
return targetPath;
};
// 1. Handle case where agent provided an absolute path
if (path.isAbsolute(normalizedPlanPath)) {
const realResolved = getRealResolvedPath(normalizedPlanPath);
if (isSubpath(realPlansDir, realResolved)) {
return normalizedPlanPath;
}
}
// 2. Try resolving relative to project root
const resolvedFromProjectRoot = path.resolve(projectRoot, normalizedPlanPath);
const realResolvedFromRoot = getRealResolvedPath(resolvedFromProjectRoot);
if (isSubpath(realPlansDir, realResolvedFromRoot)) {
return resolvedFromProjectRoot;
}
// 3. Try resolving relative to plansDir
const resolvedFromPlansDir = path.resolve(plansDir, normalizedPlanPath);
const realResolvedFromPlans = getRealResolvedPath(resolvedFromPlansDir);
if (isSubpath(realPlansDir, realResolvedFromPlans)) {
return resolvedFromPlansDir;
}References
- Ensure consistent path resolution by using a single, robust function (e.g.,
resolveToRealPath) for all related path validations. - Sanitize user-provided file paths used in file system operations to prevent path traversal vulnerabilities.
| if (existsSync(docsTarget)) { | ||
| execSync(`rm -rf "${docsTarget}"`); | ||
| } |
There was a problem hiding this comment.
Cross-Platform Compatibility Issue
Using execSync('rm -rf ...') is not cross-platform compatible and will fail on Windows environments that do not have rm installed.
Since Node.js >= 14.14.0, fs.rmSync is natively supported and works reliably across all platforms without spawning a shell process. We can use a dynamic import with top-level await to load rmSync from node:fs cleanly.
if (existsSync(docsTarget)) {
const { rmSync } = await import('node:fs');
rmSync(docsTarget, { recursive: true, force: true });
}
|
Size Change: +1.16 kB (0%) Total Size: 33.9 MB
ℹ️ View Unchanged
|
gemini-cli
Bot
added
area/core
2 participants
Summary
This PR enables support for nested directory structures within the
plansdirectory during Plan Mode. It ensures that implementation plans can be organized into subdirectories (e.g.,plans/tracks/feature-x/spec.md) and that tools likewrite_file,edit, andexit_plan_modecan correctly resolve and validate these paths.Details
resolveAndValidatePlanPathinplanUtils.tsto handle nested paths and strip the leadingplans/segment if provided by the agent.validatePlanPathto support deep directory validation within the approved plans directory.write_file: Now correctly resolves nested paths whenisPlanModeis true.edit: Preserves directory structure and handles nested plan files.exit_plan_mode: Validates and accepts nested plan file paths.ProceedAlways(Allow for session) toProceedOncewhen in Plan Mode. This prevents accidental transitions toAUTO_EDITmode, which would update the policy and potentially exit Plan Mode prematurely.build_package.jsby ensuring the target directory is cleaned before copying docs.Related Issues
Related to #17690
How to Validate
Run the following test suites to verify path resolution, tool behavior, and policy mapping:
Verify that nested paths like
tracks/my-feature/plan.mdare correctly handled by creating a plan in a subdirectory and editing it.Pre-Merge Checklist