[Bug] - Incorrectly handled absolute paths #1057
Conversation
|
|
@cursor bugbot review |
This comment was marked as outdated.
This comment was marked as outdated.
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 77abafaaa1
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
| const dirFiles = await glob(dirPattern, { | ||
| ignore: ignorePatterns, | ||
| withFileTypes: true, | ||
| // dirPattern is always relative (constructed from file.relative()), so use contextPath |
There was a problem hiding this comment.
Nested directory glob uses wrong cwd for absolute paths
When src is an absolute path, the first glob at line 59 uses cwd: undefined (defaulting to process.cwd()), causing file.relative() to return paths relative to process.cwd(). However, the nested directory glob at lines 74-79 always uses cwd: contextPath. This mismatch means when copying an absolute directory path, the dirPattern (relative to process.cwd()) is incorrectly interpreted relative to contextPath, causing the nested glob to search in the wrong location. The Python SDK correctly uses the same root_dir logic for both globs. This breaks hash calculation and tar creation for absolute directory paths.
Additional Locations (1)
mishushakov
force-pushed
the
bug-absolute-paths
branch
from
fccd229 to
d7d5308
Compare
| ...instruction, | ||
| filesHash: await calculateFilesHash( | ||
| src, | ||
| instruction.filePath.toString(), |
There was a problem hiding this comment.
JS sends unfiltered filePath to backend, Python doesn't
The JS serialize method passes the entire steps array directly to the API, including the new filePath field which contains the original absolute path and is of type PathLike (could be Buffer/URL). In contrast, Python's _serialize explicitly constructs new step objects with only type, args, force, filesHash, and forceUpload fields, filtering out filePath and resolveSymlinks. This inconsistency means the JS SDK sends potentially sensitive path information and non-string PathLike objects to the backend that the Python SDK properly excludes.
Absolute paths inside the workdir are resolved to
./<path-inside-workdir>and saved to the tar, but passed to the backed still as absolute path. But backend doesn't know about the SDK workdir, so it's unable to resolve the path correctlyNote
Fixes incorrect handling of absolute paths across JS and Python template builders.
relativizePath/relativize_pathto normalize absoluteCOPYargs while preserving originalfilePathfor hashing and uploadInstructionwithfilePath; hashing (calculateFilesHash) and logging now use it; glob/cwd logic updated to support absolute patternstarusage withmodern-tar+ gzip streaming;uploadFilerenamed param tofilePath; deps updated (modern-taradded,tarmoved to dev)filePathfor upload/hashing in async/sync flowsWritten by Cursor Bugbot for commit e2096cf. This will update automatically on new commits. Configure here.