Summary
Live/saved scan activity path extraction compares repository prefixes case-sensitively even when the path is a Windows drive or UNC path.
On ordinary Windows filesystems, a tool event can refer to the same repository file with different drive/directory casing and Codex Security then reports the activity with an empty paths list.
Reproduction / evidence
Current upstream main at 37bf87a692fc72d41f7312cc48808d699d204fba normalizes backslashes but retains case:
const prefix = `${repository.replaceAll("\\", "/").replace(/\/$/u, "")}/`;
...
const normalized = candidate.replaceAll("\\", "/");
if (normalized.startsWith(prefix)) {
...
}
commandRepositoryPaths() uses the same case-sensitive startsWith() for the concrete repository prefix.
The existing test suite already treats Windows paths as valid repository activity inputs, e.g. C:\\code\\juice-shop\\routes\\login.ts against C:\\code\\juice-shop.
A deterministic extension of that case is:
scanActivityFromEvent(
toolEvent("read_file", {
path: "c:\\CODE\\JUICE-SHOP\\routes\\login.ts",
}),
"C:\\code\\juice-shop",
)
Current behavior: paths: [].
Expected behavior: paths: ["routes/login.ts"].
The same loss occurs for absolute Windows paths embedded in shell commands and for saved-session tool calls, because both flow through the same repository-prefix extraction helpers.
Root cause
Path separators are normalized for Windows-style inputs, but prefix comparison still uses POSIX case-sensitive string semantics. Repository-path style is available from the normalized root itself, so the comparison does not need to depend on the host running the renderer.
Suggested fix
- detect Windows drive/UNC repository roots from their normalized path shape;
- compare only the concrete repository prefix case-insensitively for those roots;
- keep
$CODEX_SECURITY_REPOSITORY placeholder matching case-sensitive;
- slice the relative path from the original normalized candidate so display casing is preserved;
- add regressions for tool events, saved-session events, and command extraction.
Impact
This is an observability correctness bug. The scan still reads the file, but live activity and saved-session presentation can omit the affected source path, making Windows scan progress/details incomplete and misleading.
Summary
Live/saved scan activity path extraction compares repository prefixes case-sensitively even when the path is a Windows drive or UNC path.
On ordinary Windows filesystems, a tool event can refer to the same repository file with different drive/directory casing and Codex Security then reports the activity with an empty
pathslist.Reproduction / evidence
Current upstream
mainat37bf87a692fc72d41f7312cc48808d699d204fbanormalizes backslashes but retains case:commandRepositoryPaths()uses the same case-sensitivestartsWith()for the concrete repository prefix.The existing test suite already treats Windows paths as valid repository activity inputs, e.g.
C:\\code\\juice-shop\\routes\\login.tsagainstC:\\code\\juice-shop.A deterministic extension of that case is:
Current behavior:
paths: [].Expected behavior:
paths: ["routes/login.ts"].The same loss occurs for absolute Windows paths embedded in shell commands and for saved-session tool calls, because both flow through the same repository-prefix extraction helpers.
Root cause
Path separators are normalized for Windows-style inputs, but prefix comparison still uses POSIX case-sensitive string semantics. Repository-path style is available from the normalized root itself, so the comparison does not need to depend on the host running the renderer.
Suggested fix
$CODEX_SECURITY_REPOSITORYplaceholder matching case-sensitive;Impact
This is an observability correctness bug. The scan still reads the file, but live activity and saved-session presentation can omit the affected source path, making Windows scan progress/details incomplete and misleading.