update_project_uids passes absolute project path into resave_resources, producing malformed res:/// path and false-positive success

[vivienvoid]

Bug Description

update_project_uids appears to succeed, but in WSL/Windows testing it processed zero files because the handler passed an absolute host path into the Godot-side resave_resources() operation.

That operation prepends res:// to any non-resource path, so a path like /mnt/c/Code/godot-mcp-probe becomes res:///mnt/c/Code/godot-mcp-probe/, which is not a valid project resource root.

The tool then returns a success envelope even though no scenes or scripts were found.

Steps to Reproduce

1. Configure godot-mcp to use a working Godot 4.6+ executable
2. Use a valid Godot project path, e.g. /mnt/c/Code/godot-mcp-probe
3. Call:

{
  "projectPath": "/mnt/c/Code/godot-mcp-probe"
}

4. Observe debug output from the underlying operation

Actual Behavior

Debug output shows:

Using project path: res:///mnt/c/Code/godot-mcp-probe/
Found 0 scenes
Found 0 scripts/shaders
Resave operation complete

But the MCP tool still reports success.

Expected Behavior

The tool should either:

• operate on the current project root via res://, or
• convert the path into a valid resource path before passing it to GDScript,

and it should not report success if zero files were processed due to malformed input.

Root Cause

Current flow appears to be:

1. handleUpdateProjectUids() passes absolute args.projectPath
2. executeOperation() sends it as project_path
3. resave_resources() does:
   • if not project_path.begins_with("res://"): project_path = "res://" + project_path
4. absolute /mnt/c/... becomes malformed res:///mnt/c/...
5. recursive search finds nothing
6. success is still returned because stderr does not contain Failed to

Direct Proof

Calling the same Godot operation directly with default params so it uses res:// works correctly:

• found 3 scenes
• saved 3 scenes
• found 1 script/shader

So the underlying resave logic can work. The broken part is parameter plumbing.

Proposed Fix

Simplest fix in the TypeScript handler:

• do not pass absolute projectPath into resave_resources
• call it with empty/default params so the script uses res://

Alternative:

• update resave_resources() to detect absolute filesystem paths and convert them correctly instead of blindly prefixing res://

Additional Improvement

handleUpdateProjectUids() should treat these cases as failure conditions:

• malformed resource root
• zero files found in an otherwise valid project
• obvious path mismatch in debug output

Environment

• OS: WSL2 (Ubuntu) driving Windows Godot executable through wrapper
• Godot: 4.6.2.stable.official.71f334935
• MCP server: local build of current repo HEAD as of probe

[vivienvoid]

Opened a fix PR for this: #104\n\nSummary:\n- stop passing the absolute host project path into resave_resources\n- pass instead so the operation stays rooted in the active project\n- verified live against Godot 4.6.2 with the probe project; the tool now finds and processes scenes/scripts instead of returning a false-positive zero-file success

[vivienvoid]

Opened a fix PR for this: #104

Summary:

• stop passing the absolute host project path into resave_resources
• pass res:// instead so the operation stays rooted in the active project
• verified live against Godot 4.6.2; the tool now finds and processes scenes/scripts instead of returning a false-positive zero-file success