Package DevinX Connector 0.1.1 for Microsoft Store - #58
Conversation
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
| "publisherDisplayName": "DevinX Tools", | ||
| "packageFamilyName": "DevinXTools.DevinXConnector_ydtgrt4yd5wrc", | ||
| "msaAppId": "7d1237e7-6265-48ab-adf5-2a12f5d81101", | ||
| "version": "0.1.1.0", |
There was a problem hiding this comment.
🔍 MSIX package version (0.1.1.0) diverges from the actual runtime version (0.1.4) and the wrapped 0.1.0 build folder
The Store package is built by wrapping the DevinX-Connector-0.1.0-windows-x64 payload folder (scripts/connector/build-windows-msix.mjs:47-52, matching connectorVersion = '0.1.0' in scripts/connector/build-windows.mjs:22) and is stamped with MSIX version 0.1.1.0 from connector/windows-msix/store-identity.json. Meanwhile the bundled runtime reports CONNECTOR_VERSION = '0.1.4' (bridge/src/version.ts:1), which is what the mobile compatibility handshake actually checks against MINIMUM_SUPPORTED_CONNECTOR_VERSION = '0.1.2'. Functionally this is fine (the handshake uses the runtime version, not the MSIX version), but the three different version numbers for the same artifact are confusing and worth confirming intent, especially since the PR title says "0.1.1".
Was this helpful? React with 👍 or 👎 to provide feedback.
| uap10:RuntimeBehavior="win32App" | ||
| uap10:TrustLevel="mediumIL"> | ||
| <uap:VisualElements | ||
| DisplayName="DevinX Connector" | ||
| Description="Securely connect DevinX on iPhone to Devin running on this Windows PC." | ||
| BackgroundColor="transparent" | ||
| Square150x150Logo="Assets\Square150x150Logo.png" | ||
| Square44x44Logo="Assets\Square44x44Logo.png" /> | ||
| <Extensions> | ||
| <desktop:Extension | ||
| Category="windows.startupTask" | ||
| Executable="DevinXConnector.exe" | ||
| EntryPoint="Windows.FullTrustApplication"> | ||
| <desktop:StartupTask | ||
| TaskId="DevinXConnectorStartup" | ||
| Enabled="false" | ||
| DisplayName="DevinX Connector" /> | ||
| </desktop:Extension> | ||
| </Extensions> | ||
| </Application> | ||
| </Applications> | ||
| <Capabilities> | ||
| <rescap:Capability Name="runFullTrust" /> |
There was a problem hiding this comment.
🔍 AppxManifest declares runFullTrust alongside mediumIL trust level
connector/windows-msix/AppxManifest.xml.template:32-33 sets uap10:RuntimeBehavior="win32App" and uap10:TrustLevel="mediumIL" on the Application while :54 declares the runFullTrust restricted capability, and the startup-task extension uses EntryPoint="Windows.FullTrustApplication". The app must launch a Node child process and use current-user DPAPI, so it genuinely needs full trust. This particular attribute combination is intentional per the verify script's assertions, and MakeAppx pack + Store certification would reject a truly invalid manifest, so I did not flag it — but the mediumIL + runFullTrust pairing is unusual enough to be worth confirming against a successful real MSIX build/cert run on Windows.
Was this helpful? React with 👍 or 👎 to provide feedback.
1 participant
What changed
9N52Z3FVMFH8Why
The public Store listing still serves the older Connector. This update packages the current Connector behavior—including the model-catalog refresh—using the reserved Microsoft Store identity and a Store-managed install/update path.
User impact
Windows 11 x64 users receive a normal Microsoft Store installation and update experience. Mobile onboarding links directly to the official Store listing, and the assisted setup prompt verifies the exact Store identity rather than permitting unsigned or guessed artifacts.
Validation
npm run lintnpm run typechecknpm run test -- --ci --runInBand— 86 suites / 665 tests passednpm run buildnpm run audit— passed the bounded advisory gatenpm run connector:verify:windows:storegit diff --checkThe Windows workflow will additionally build, unpack, checksum, and verify the real MSIX on
windows-2025before it is used for Partner Center.