fix(harness): prevent LocalFilesystemSpec from falling back to user.dir

[BeginnerCong]

AgentScope-Java Version

2.0.1-SNAPSHOT

Description

Fixes #2065. When project is not set, LocalFilesystemSpec now defaults to the agent workspace instead of System.getProperty("user.dir"). This prevents unintended exposure of the JVM working directory in non-CLI scenarios (web apps, embedded agents).

Root Cause

LocalFilesystemSpec.toFilesystem() had a default branch that used System.getProperty("user.dir") as the lower layer of the OverlayFilesystem. In non-CLI scenarios (web applications, embedded agents), user.dir points to the JVM's working directory, which is unrelated to the agent's intended project scope. This caused the agent to be able to read files it should not have access to (source code, config files, deployment configs, etc.) through the filesystem lower layer.

Changes

• Modified LocalFilesystemSpec.toFilesystem() to default effectiveProject to workspace instead of user.dir
• Updated Javadoc comments to reflect the new default behavior
• Updated comment in HarnessAgentBuilderSupport.resolveFilesystem()
• Added 4 unit tests to verify the fix

Checklist

• Code has been formatted with mvn spotless:apply
• All tests are passing (mvn test)
• Javadoc comments are complete and follow project conventions
• Related documentation has been updated (e.g. links, examples, etc.)
• Code is ready for review

[CLAassistant]

All committers have signed the CLA.

[BeginnerCong]

@cla-bot check

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[AgentScopeJavaBot]

🤖 AI Review

This is a clean, focused security fix that correctly addresses the root cause of issue #2065. The change replaces the user.dir fallback with workspace in LocalFilesystemSpec.toFilesystem(), preventing unintended exposure of the JVM working directory in non-CLI scenarios (web apps, embedded agents). The Javadoc updates are consistent, the unused Paths import is cleanly removed, and the four unit tests provide solid coverage of both the fix and the existing explicit-project behavior.

One note for the author: Line 393 of HarnessAgentBuilderSupport.java still contains a stale comment referencing project=${user.dir} — consider updating it to reflect the new default (project=workspace) for consistency, though this is outside the current diff scope.

[AgentScopeJavaBot]

[nit] When project == null, effectiveProject equals workspace, so policyRoots ends up with workspace added twice (lines 289 and 290). PathPolicy.of() handles duplicates gracefully, but a simple guard would keep the list clean:

policyRoots.add(effectiveProject);
if (!effectiveProject.equals(workspace)) {
    policyRoots.add(workspace);
}

Not blocking — purely cosmetic.

[AgentScopeJavaBot]

[praise] Excellent test coverage. The four tests systematically verify: (1) default fallback to workspace works, (2) no access to files outside workspace when project is unset, (3) explicit project is respected, and (4) user.dir is not leaked when project is set. The use of @TempDir for isolation and the finally cleanup in projectSet_cannotReadUserDir are well done.

[AgentScopeJavaBot]

🤖 AI Review

This is a clean, focused security fix that correctly addresses the root cause of issue #2065. The change replaces the user.dir fallback with workspace in LocalFilesystemSpec.toFilesystem(), preventing unintended exposure of the JVM working directory in non-CLI scenarios (web apps, embedded agents). The Javadoc updates are consistent, the unused Paths import is cleanly removed, and the four unit tests provide solid coverage of both the fix and the existing explicit-project behavior.

One note for the author: Line 393 of HarnessAgentBuilderSupport.java still contains a stale comment referencing project=${user.dir} — consider updating it to reflect the new default (project=workspace) for consistency, though this is outside the current diff scope.

[AgentScopeJavaBot]

[nit] When project == null, effectiveProject equals workspace, so policyRoots ends up with workspace added twice (lines 289 and 290). PathPolicy.of() handles duplicates gracefully, but a simple guard would keep the list clean:

policyRoots.add(effectiveProject);
if (!effectiveProject.equals(workspace)) {
    policyRoots.add(workspace);
}

Not blocking — purely cosmetic.

[AgentScopeJavaBot]

[praise] Excellent test coverage. The four tests systematically verify: (1) default fallback to workspace works, (2) no access to files outside workspace when project is unset, (3) explicit project is respected, and (4) user.dir is not leaked when project is set. The use of @TempDir for isolation and the finally cleanup in projectSet_cannotReadUserDir are well done.