Skip to content

fix(paths): recognize Windows absolute paths (drive-letter/UNC) in parse_uri - #304

Open
Dan Shapiro (danshapiro) wants to merge 1 commit into
microsoft:mainfrom
danshapiro:fix/windows-absolute-paths
Open

fix(paths): recognize Windows absolute paths (drive-letter/UNC) in parse_uri#304
Dan Shapiro (danshapiro) wants to merge 1 commit into
microsoft:mainfrom
danshapiro:fix/windows-absolute-paths

Conversation

@danshapiro

Copy link
Copy Markdown
Contributor

Problem

On native Windows, parse_uri classified only file:// URLs, POSIX absolute paths (/...), and ./ / ../ relative paths as file URIs. Windows absolute paths (C:\..., C:/...) and UNC paths (\\server\share\...) fell through to the package-name heuristic, so no source handler claimed them:

BundleNotFoundError: No handler for URI: C:\Users\dan\.amplifier\cache\amplifier-bundle-filesystem-...\modules\tool-apply-patch

Two real-world impacts (reproduced on Windows 11, native PowerShell, amplifier 2026.08.14):

  1. Local bundle/behavior references in settings.yaml (e.g. bundle.app: [C:/Users/dan/code/bundle-the-usual/behaviors/the-usual.yaml]) fail to compose: Failed to compose behavior ....
  2. Relative module entries inside cached git bundles are resolved by the app to absolute OS path strings before hitting the resolver; on Windows every such module fails activation and strict mode aborts session startup ("Module Activation Failed", suggesting AMPLIFIER_ALLOW_PARTIAL_BUNDLE=1).

Fix

In parse_uri, recognize drive-letter (``:followed by` or `/`) and UNC (`\`) prefixes as `scheme="file"`, before the package-name fallback. Unconditional (not `os.name`-gated): on POSIX these inputs were previously misclassified as package names too — the file handler now at least reports an accurate `File not found`.

Tests

Added 4 tests to tests/test_paths.py (drive-letter forward/backslash, UNC, file://C:/...). Local run: 56 passed; the 5 failing TestNormalizePath tests fail identically on unmodified main (pre-existing POSIX-only assertions on a Windows test box, unrelated to this change). ruff check and ruff format --check clean.

Fixes microsoft/amplifier#374

…rse_uri

C:/..., C:\..., and \\server\share\... URIs previously fell through to the
package-name heuristic, so no source handler claimed them and resolution
failed with 'No handler for URI' on native Windows. This surfaced when
settings.yaml referenced local behaviors/bundles via Windows paths, and when
relative module entries inside cached bundles were resolved to absolute OS
path strings (strict mode then aborted session startup).

Fixes microsoft/amplifier#374
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

bug(windows): parse_uri does not recognize Windows absolute paths - 'No handler for URI' for local behaviors and bundle modules

1 participant