Repository navigation
fix(cli): refuse a non-URL install-from-source source up front - #3166
Conversation
install-from-source treats its positional as a URL. A local path is only rejected later, when the download layer fails to parse it as a source URL, and the error does not say what to run instead. The CLI now refuses a positional that is not an http(s) URL with INVALID_ARGS before any work and points at `install <app> <path>` for local builds. The deprecated SDK `isTrustedInstallSourceUrl` reports an unparsable source as INVALID_ARGS instead of throwing a TypeError. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
There was a problem hiding this comment.
All reported issues were addressed across 4 files
Tip: cubic used a learning from your PR history. Let your coding agent read cubic learnings directly with the cubic MCP.
Re-trigger cubic
…refix The prefix check let `http://`, `https://` and `http://exa mple.com` through, so they still failed later in the download layer without the `install <app> <path>` hint. Parse the source with URL.parse and require an http or https protocol, so every non-URL source is refused up front. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The download layer and isTrustedInstallSourceUrl each built the same INVALID_ARGS "Invalid source URL" error. Build it in one place so the two refusals cannot drift, and test that both reject an unparsable source with the same code and message. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
This PR is ready at f27001d. The CLI now refuses a non-URL install-from-source source up front, and the tests cover the cases from the issue. Not blocking: the http(s) check in Both cubic-dev-ai P3 threads are fixed at this head and can be resolved: the duplicated "Invalid source URL" payload is now one CI shows one check, and it passes. I read the diff and did not run the tests locally. MCP, the SDK and direct daemon requests are not guarded by this change, which matches the CLI-only scope of the issue. Nothing blocks merge. |
thymikee
added
the
ready-for-human
…token-attach-c41aff * commit 'd396f3b509d9ed7cddaf170351ea6cf34e02ac16': fix(provider-webdriver): harden BrowserStack app references and endpoints (#3169) fix(android): back off a timed-out snapshot helper session and bound content re-captures (#3160) fix: centralize confirmed daemon retirement (#3126) fix: bind daemon registration writes to the acquired owner (#3125) fix: return confirmed daemon termination outcomes (#3124) refactor(move): share daemon registration and shutdown report modules (#3123) fix: preserve process lock exclusion across publication and reclaim (#3122) fix(cli): refuse a non-URL install-from-source source up front (#3166) fix(daemon): start a lease's TTL when its allocation completes (#3165) fix(android): fail doctor when adb is the Windows binary on a POSIX host (#3157) 0.21.20 0.21.19 # Conflicts: # src/daemon/server/daemon-runtime-metadata-ownership.test.ts
Brings feat/testmu-provider-plugin (915e572) up to date with main, which since landed the split-out callstack#3165 (lease TTL), callstack#3166 (install-from-source URL refusal), callstack#3169 (BrowserStack app references, hub helpers, materialized upload) and callstack#3173 (Limrun attached instances). Main's reviewed versions win for the split-out code: appFileUploadForm with {provider, service}, resolveHubAppReference with parseReference, parseBrowserStackAppReference, isHttpUrl in install, the lease work pass only when a provider allocates, and the upload file check in appFileUploadForm rather than runtime-deployment. Re-applied on top only what the migration needs: provider profile-field refusal (connect, WebDriver and Limrun allocation, refused repeat allocation keeps its lease), optional auth on fetchProviderVerificationJson for TestMu's public catalog, and the provider-webdriver/plugin barrel without asRecord. The TestMu plugin now uses asOptionalRecord from @agent-device/kernel/record, parses lt:// references itself and uploads a public URL before delegating to resolveHubAppReference, and passes {provider, service} to appFileUploadForm. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2 participants
Summary
Split out of #3118. This change affects every provider.
install-from-sourcetreats its positional argument as a URL. Until now, a local path was only rejected later, by the download layer, with no pointer to the right command.INVALID_ARGSbefore doing any work, and points atinstall <app> <path>.isTrustedInstallSourceUrlnow reports an unparsable source asINVALID_ARGSinstead of throwing a TypeError.Validation
pnpm check:affected --runpasses.🤖 Generated with Claude Code