[Release] VScode extension for LM/SL

[Seijboldt]

The VS Code extension I showed a while back is finally available after several rounds of beta testing.
What originally started as a way to stop copy-pasting scripts between VS Code, Git and LogicMachine gradually turned into a complete development workflow for LM and SL devices.
Current public functionality includes:

• Sync scripts between device and VS CodeDiff viewer for local vs device changes Auto-upload on saveRun scripts directly from VS Code Enable/disable scriptsCreate, edit and delete scripts Live logs and error monitoring Multi-device support Object browser with live updates Storage viewer and Support for Cloudflare Access and reverse-proxied deployments

Get the extension here and read the quickstart before you ask how it works.

A few gifs and screenshots:


Screenshot of the extension menu in command palette:


We have added a live-object view with rapid toggle booleans and write analog values using the built in websocket from the LM/SL.
This shows on-change highlighting, filtering, sorting alphabetical or by most recent change, etc.



Enhanced and refined the diff view when syncing from device:


If the storage viewer app is installed on the LM/SL object storage is also viewable:


The extension is actively developed, so if you run into issues or have feature requests, post them here and I'll take a look.
Thanks to everyone who provided feedback and helped identify edge cases during development.

[chasler]

Hi,

First thanks for the effort. This plugin is really a needed one to use AI integration for code assist. I think your work will be very useful in the future. Unfortunately this extension doesn't work in my system right now, so here is what I found.

SDlink for SpaceLynk / LogicMachine — bug report

Extension: sdlink.sdlink-vsc-sl, version 0.1.9
VS Code: 1.134.0, Windows (win32)
LM5 controller: reached over HTTPS, authenticated via the extension's own device profile (URL + username; password in VS Code SecretStorage)
Observed: 2026-09-08

Three problems found in one session spent setting up the extension and using it to deploy a single library update. Each is reported as observed, with the evidence that supports it.

1) Pushing a "user" library does not reach the device, with no error shown

Pushing a modified library (a .lua file whose metadata entry has "type": "user") through the sync dialog reports success ("Sync complete — 1 pushed"), and the Script Errors view stays at 0. The controller still holds the previous content.

Verified independently: a LogicMachine backup taken immediately before and immediately after the push showed byte-for-byte identical content (same size, same SHA-256). The push notification was the only signal claiming success; the controller's own backup, and later a full reload of the LM web editor, both still showed the old version.

Reproduced twice: once in the original workspace folder, once in a brand-new workspace folder created solely to rule out anything folder-specific. Same result both times.

Working hypothesis, not verified against the source: libraries carry "id": "undefined" in .sdlink-metadata.json rather than a numeric id like scripts do. They may be routed to a push path that doesn't work, or that silently no-ops.

Workaround used: pasted the library content by hand into the LM web editor, then confirmed with a full sync in the device-to-local direction, which does work reliably.

2) Local files move between folders on their own, with no user input

Files whose metadata says "category": "User library" get placed under a folder named System one moment and User library the next, with no sync command run, no click, no keystroke, the editor simply left open and idle. Watched happening in real time over a few minutes, including mid-command: a git add on a set of file paths failed partway through because one of the files had already moved to a different folder in the seconds between being listed and being staged.

Confirmed not caused on our side: it happened in a brand-new workspace folder synced for the first time, before any push or edit in it. The controller's own content was unaffected across this churn, confirmed by two LM backups minutes apart, byte-for-byte identical for the affected files. A single file's category field was seen to flip between "System" and "User library" across two consecutive reads, with no action in between.

Impact: this makes the local mirror unusable for version control as-is, since a git status taken minutes apart shows a different, unforced diff each time, on files nobody touched.

3) No usable debug output could be found

Output: Show Output Channels, filtered on sdlink, space, and logic, returned no SDlink channel in the standard Output panel.

The extension's own sidebar (Script Logs, Script Errors, Formatted Logs) stayed empty even right after the silent failure described in point 1.

A notification referenced "Skipped ..." lines and pointed at an "SDlink Debug" output channel for detail, but that channel could not be located anywhere, by name or by content search.

Consequence: when something fails silently, nothing lets a user see why, beyond a toast notification whose wording does not distinguish "pushed and applied" from "pushed and discarded".

Suggested priority: point 1 has the real operational consequence, since a false success is worse than a visible error. Point 3 compounds it, since no diagnostic path was available. Point 2 is disruptive but self-evident, and caused no change on the controller in our case.

Thanks for the job!

[Seijboldt]

Hi!
I really appreciate the reply, one of the core principles for this extension is to lessen the need to copy and paste, seems libraries was almost forgotten.
A wall of a LLM response isn't really what I had hoped as the first feedback, but it's good enough.

When I was stripping functionality for this to only handle the SL/LM ecosystem some things obviously didn't get caught in testing, thanks for the feedback.

Most of these fixes were already done alongside some smaller bug and typo fixes, should be pushed to prod in an hour or two.
1-userlib pushes now land on device and any future silent no-op is turned into a proper error.
2-main issue here was a name and type collision, I've added a background reconciliation to prevent renaming of files.
3-It was never intended to give a complete debug log when connected to our internal systems as they handled that, I've re-enabled this locally for the extension.

Hope to have some more bug reports in the future alongside feature requests from you 

[chasler]

Hi, loaded version 0.1.10

First, thanks for the responsiveness!
Modifying an event script --> works
Modifying a resident script --> works
Modifying a scheduled script --> works
Modifying initscript.lua --> doesn't work
Modifying userlib.lua (Common functions) --> doesn't work
Modifying a User Library --> doesn't work
No error reported, identical message in all cases: "SDlink: Uploaded"

Is there anything I can do to help your debug?
Thanks

[Seijboldt]

0.1.11 released which handles the userlib and initscript way better with a read of sha-256 hex of the script body compared after upload to confirm changes sticks, errors if not.
Uploaded message no longer appears when LM/SL drops a save, all uploads are verified in a similar way as the userlib and initscript now.
I did notice some extension caching can be sticky in VScode, no clue how to solve that so if the fix doesn't actually fix this try clearing the vscode cache.

[chasler]

0.1.11 released which handles the userlib and initscript way better with a read of sha-256 hex of the script body compared after upload to confirm changes sticks, errors if not.
Uploaded message no longer appears when LM/SL drops a save, all uploads are verified in a similar way as the userlib and initscript now.
I did notice some extension caching can be sticky in VScode, no clue how to solve that so if the fix doesn't actually fix this try clearing the vscode cache.

Hi,

Modifying initscript.lua --> works
Modifying userlib.lua (Common functions) --> works
Modifying a User Library --> works

Thanks a lot!