fix(interface): handle Windows drive-letter paths in --workspace-file

[itzzdev09]

Fixes #1257

Bug

--workspace-file treats the colon in a Windows drive letter as the PATH:DEST separator. A bare path like C:\temp\wordlist.txt gets split into source C and destination \temp\wordlist.txt, so argument parsing rejects it before the scan starts (no file named C exists).

Root cause is a little wider than the single rpartition call the issue points at: both resolve_workspace_files and _workspace_file_dest independently call spec.rpartition(":") and assume any colon found is a real separator, so fixing one without the other would have left the destination still wrong for the bare-path case.

Fix

Added _split_workspace_spec, used by both call sites, that detects the drive-letter case specifically: a single-letter raw from rpartition immediately followed by \ or / in what would be dest. In that case the whole spec is treated as the path with no explicit destination.

The explicit PATH:DEST form keeps working even when PATH itself starts with a drive letter (C:\temp\wordlist.txt:dest/file), since rpartition's rightmost split there lands on the real :dest/file separator, not the drive letter's colon — raw in that case is the whole C:\temp\wordlist.txt, not a single letter, so the drive-letter check doesn't fire. Relative and POSIX paths are unaffected either way.

Testing

Ran the exact repro from the issue for real (this is a Windows machine):

PS> strix -n --target https://example.com --workspace-file C:\temp\wordlist.txt

Before the fix: exits with the "'C' is not an existing file" argument-parsing error described in the issue.
After the fix: resolves correctly.

Added:

• 3 parametrized cases against _split_workspace_spec directly (bare \-path, bare /-path, and the explicit PATH:DEST form with a drive-letter source) — these fail to even collect against the old code, since the old code has no such helper to import, which is a reasonable proxy for "this is new coverage, not just documentation."
• One end-to-end test through resolve_workspace_files using tmp_path directly (skipped on non-Windows, since tmp_path is only drive-letter-shaped here).

uv run pytest tests/test_workspace_files.py — 17 passed. uv run pytest -k workspace across the full suite — 32 passed, no regressions. ruff check/ruff format --check/mypy/bandit all clean on the two changed files (one pre-existing, unrelated ruff finding elsewhere in utils.py at line 877, far from this change).

[greptile-apps]

Confidence Score: 4/5

The PR should not merge until the drive-letter heuristic preserves valid single-letter PATH:/workspace/... specifications.

Findings

1.  Single-letter sources are rejected ▶

Prompt To Fix All With AI

### Issue 1
strix/interface/utils.py:1729-1730
A valid `PATH:DEST` spec such as `a:/workspace/input.txt`, where `a` is an existing file, is now mistaken for a Windows drive path. This branch returns the entire spec as the source, so `resolve_workspace_files` looks for a file named `a:/workspace/input.txt` and rejects the argument. Absolute destinations under `/workspace/` are explicitly supported, so the drive-letter check must preserve this existing interpretation.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

Summary

• Reuses the new parser for both source resolution and workspace destination selection.
• Adds direct coverage for slash and backslash drive paths plus a Windows-only end-to-end test.
• Introduces an ambiguity for existing single-letter sources paired with absolute /workspace/... destinations.

[itzzdev09]

Good catch, thanks — this was a real regression.

`a:/workspace/input.txt` (single-letter source, explicit absolute `/workspace/` destination) has the exact same shape as a Windows drive-letter path once `rpartition(":")` splits it, so the drive-letter check was firing on it too.

Fixed in bdb92ad: the drive-letter case now only applies when `dest` doesn't start with `/workspace/`, since that's the one signal that reliably distinguishes "this is a real explicit destination" from "this is actually a drive letter." Both forms now work correctly — verified with two new tests, one hitting `_split_workspace_spec` directly and one going through `resolve_workspace_files` end-to-end with a real single-letter file (via `monkeypatch.chdir`, so the spec is genuinely `a:/workspace/input.txt`-shaped rather than a full path that happens to start with `a`). Both fail against the previous commit and pass now.

Full suite: 56 passed (`-k workspace`), no regressions.