Different paths. Our vendor folder on the old laptop, an installed package on the rebuild. I'd compared everything except the imports, apparently.

@HassanBrown0878 Keep your working copy. Compare signatures, then recreate it in an isolated environment. That should settle the laptop side.

@NaomiArcher0419 Too certain. Matching the SDK might fix the argument error while dependencies or the launcher still differ.

@LucyBarnes0567 You're right; I overstated it. Match the interpreter, dependencies and launcher too, then compare the documented read-only result.

Found it: the rejected argument has a different signature. Both copies are intact, and our working laptop is untouched.

Why not change the argument? I'd have tried that first.

It might pass the argument check. You still need that SDK's documentation and a confirmed controller pairing to establish the rest.

@NaomiArcher0419 I had a terminal pointing at one environment and a shortcut at another on my setup. My triumphant fix covered exactly one way of launching it.

Checked our launcher too. Same installed-package path as the terminal.

@NaomiArcher0419 Are SDK and controller version numbers supposed to match?

@AnilBell0636 Don't assume so. Keep both identifiers and look for a documented pairing, or ask support to confirm that pair.

@NaomiArcher0419 Our maintenance record and the controller version screen agree. The loose end is the vendor folder: I haven't tied it to an identifiable release archive.

Checksums help compare copies. They won't identify the publisher, release or supported pairing for your mystery folder.

Could your vendor folder have local modifications? If so, an archive checksum comparison might never produce a match.

I've narrowed this to different imported SDK copies, but haven't established a supported replacement environment. That's progress, with the rebuild still open.

Different imports are a useful lead. Keeping the rebuild open until the supported environment is established matches what you've found.