New macos update causes {"code": null} error

[nosknut]

I have seen this problem on 2 macs now for a pair of students i tutor. The tirst one was unsure of what had changed but the second student pointed out he recently updated from "Big Sur" to "Sonoma".

The error message is produced by these lines in the vscode-areduino extension codebase: https://github.com/microsoft/vscode-arduino/blob/main/src/arduino/arduino.ts#L863-L866

The { "code": null } error comes from the reason object and seems to me the nodejs spawn function is producing a null error code.

I have attempted to install the arduino-cli manually on the first student's computer and using the cli directly through a terminal poses no problems. I was unable to configure the arduino extension to use the cli instead of the bundled cli in the time available.

It seems clear that the issue lies between the run function i linked above and the arduino-cli.

This could be caused by filesystem access issues related to the new os or an issue with the extension being able to execute the command?

[mediafailure]

Identical to the bug I'm seeing after the new macOS update.

[dbmzzo]

I believe you are correct that this is a permissions issue. I'm experiencing the same thing after updating to Sonoma, and in the Mac's Console.app, I see the following for each attempt to verify or upload a sketch:

syspolicyd | Terminating process due to Gatekeeper rejection

[nosknut]

I believe you are correct that this is a permissions issue. I'm experiencing the same thing after updating to Sonoma, and in the Mac's Console.app, I see the following for each attempt to verify or upload a sketch:

syspolicyd | Terminating process due to Gatekeeper rejection

Please please please throw the solution in here if you figure it out 🙏

[dbmzzo]

I believe you are correct that this is a permissions issue. I'm experiencing the same thing after updating to Sonoma, and in the Mac's Console.app, I see the following for each attempt to verify or upload a sketch: syspolicyd | Terminating process due to Gatekeeper rejection

Please please please throw the solution in here if you figure it out 🙏

After some digging around I did find a solution that worked for me. The trick was to toggle some special permissions for the VSCode app in System Settings. What I did was:

1. Go to System Settings
2. Go the the Privacy & Security section
3. Select the Full Disk Access option
4. Click the "+" button to add Visual Studio Code, or make sure the toggle is "On" if VSCode is already in the list
5. Repeat the process for the Developer Tools and App Management sections within Privacy & Security section

Quit and restart VSCode and see if the extension now works.

Interestingly, I was able to remove the special permissions after VSCode started working and it continued to work just fine.

[bringert]

I believe you are correct that this is a permissions issue. I'm experiencing the same thing after updating to Sonoma, and in the Mac's Console.app, I see the following for each attempt to verify or upload a sketch: syspolicyd | Terminating process due to Gatekeeper rejection

Please please please throw the solution in here if you figure it out 🙏

After some digging around I did find a solution that worked for me. The trick was to toggle some special permissions for the VSCode app in System Settings. What I did was:

1. Go to System Settings
2. Go the the Privacy & Security section
3. Select the Full Disk Access option
4. Click the "+" button to add Visual Studio Code, or make sure the toggle is "On" if VSCode is already in the list
5. Repeat the process for the Developer Tools and App Management sections within Privacy & Security section

Quit and restart VSCode and see if the extension now works.

Interestingly, I was able to remove the special permissions after VSCode started working and it continued to work just fine.

Awesome, I can confirm that this fixes (well, works around) the issue.

[tsamppa]

@dbmzzo I had the same problem for days and finally with your help this got solved ! Now VSCode verifies and compiles the .ino again. Thanks!

[JM-FRANCE]

I don't see that as an issue but really for what it is for: your own security

You understand that giving Visual Studio Code full access to your whole disk creates a risk (if there is a bug or vulnerability in vscode then your whole Mac might be at risk).

It's unfortunate that vscode needs read / write access to areas that are off limits. That's a design flaw there.

that was a good note though (if that works after a reboot)

Interestingly, I was able to remove the special permissions after VSCode started working and it continued to work just fine seems vscode then only need to access whatever location only once and then be done with it...

If that works then it would be a sound advice to revoke the elevated rights if they are not needed.

[ScreamZ]

@benmcmorran @elektronikworkshop @yaohaizh @gcampbell-msft Hello guys, can anyone of you have a look at this very annoying issue for MacOS users?

Thanks

[RoXuS]

I believe you are correct that this is a permissions issue. I'm experiencing the same thing after updating to Sonoma, and in the Mac's Console.app, I see the following for each attempt to verify or upload a sketch: syspolicyd | Terminating process due to Gatekeeper rejection

Please please please throw the solution in here if you figure it out 🙏

After some digging around I did find a solution that worked for me. The trick was to toggle some special permissions for the VSCode app in System Settings. What I did was:

1. Go to System Settings
2. Go the the Privacy & Security section
3. Select the Full Disk Access option
4. Click the "+" button to add Visual Studio Code, or make sure the toggle is "On" if VSCode is already in the list
5. Repeat the process for the Developer Tools and App Management sections within Privacy & Security section

Quit and restart VSCode and see if the extension now works.

Interestingly, I was able to remove the special permissions after VSCode started working and it continued to work just fine.

THX

[fredsa]

EDIT: Based on additional experience with this issue, I now believe that I had two issues when I originally wrote this comment: 1) a quarantined extension, indicated by the @ in the file permissions, 2) the issue that is fixed following @dbmzzo's instructions. See also my new comment below.

Original comment unedited: — I was able to resolve the {"code": null}) error on an M1 using these steps:

1. Uninstall the Arduino (vsciot-vscode.vscode-arduino) extension
2. Reload (restart) VS Code
3. Important: Make sure the the extension has actually been removed from disk:
   • Use ls -ld ~/.vscode/extensions/vsciot-vscode.vscode-arduino-* to see whether the extension is still there
   • If that folder does still exists, restart VS code again --> wait a few seconds --> run ls -ld … again to check
   • Once the folder has actually been deleted, ls -ld … will report No such file or directory
4. Once the extension is gone from disk, reinstall the Arduino extension
5. The extension should now work normally

Additional notes:

• On my machine I always need to restart VS Code twice after uninstalling the extension. Otherwise the extension is not actually removed from disk. YMMV.
• The broken Arduino extension was working fine before the upgrade to Sonoma.
• The arduino-cli.app file permissions of the old (broken on Sonoma) extension were: -rwxr-xr-x@ 1 fredsa primarygroup 27917936 Aug 7 22:14 /Users/fredsa/.vscode/extensions/vsciot-vscode.vscode-arduino-0.6.0-darwin-arm64/assets/platform/darwin-arm64/arduino-cli/arduino-cli.app. Unfortunately, I did not run xattr -l …, so I don't know what that @ was representing. Whatever it was, it was either added as part of the OS upgrade to Sonoma, or is an attribute that Sonoma has a problem with, but the previous OS did not.
• After reinstalling the Extension on Sonoma, the new (working on Sonoma) file permissions were -rwxr-xr-x 1 fredsa primarygroup 27917936 Nov 5 12:43 /Users/fredsa/.vscode/extensions/vsciot-vscode.vscode-arduino-0.6.0-darwin-arm64/assets/platform/darwin-arm64/arduino-cli/arduino-cli.app

Finally, while I don't think @dbmzzo's steps were needed, for completeness sake, I did try those settings first. Here are the steps I actually followed:

1. Granted VS Code access under "Privacy & Security > {Full Disk Access, Developer Tools, App Management}" --> Did not appear to fix anything for me.
2. Uninstalled Arduino extension --> restarted VS code a couple of times --> confirmed ~/.vscode/extensions/vsciot-vscode.vscode-arduino-0.6.0-darwin-arm64 was gone --> reinstalled Arduino extension --> extension immediately started working again
3. Undid the grants for VS Code in "Privacy & Security > {Full Disk Access, Developer Tools, App Management}" --> Uninstalled Arduino extension --> confirmed directory was gone --> reinstalled Arduino extension --> extension was still working

That last step (#3) suggests to me that the "Privacy & Security > {Full Disk Access, Developer Tools, App Management}" settings are not needed, but I could be wrong. It's possible that my machine had two issues: a) the broken extension that needed to be reinstalled on Sonoma, b) VS code needed one-time access to make a change that was granted by the Privacy & Security settings.

[nosknut]

I was able to resolve the {"code": null}) error on an M1 using these steps:

1. Uninstall the Arduino (vsciot-vscode.vscode-arduino) extension
2. Reload (restart) VS Code
3. Important: Make sure the the extension has actually been removed from disk:
   • Use ls -ld ~/.vscode/extensions/vsciot-vscode.vscode-arduino-* to see whether the extension is still there
   • If that folder does still exists, restart VS code again --> wait a few seconds --> run ls -ld … again to check
   • Once the folder has actually been deleted, ls -ld … will report No such file or directory
4. Once the extension is gone from disk, reinstall the Arduino extension
5. The extension should now work normally

Additional notes:

• On my machine I always need to restart VS Code twice after uninstalling the extension. Otherwise the extension is not actually removed from disk. YMMV.
• The broken Arduino extension was working fine before the upgrade to Sonoma.
• The arduino-cli.app file permissions of the old (broken on Sonoma) extension were: -rwxr-xr-x@ 1 fredsa primarygroup 27917936 Aug 7 22:14 /Users/fredsa/.vscode/extensions/vsciot-vscode.vscode-arduino-0.6.0-darwin-arm64/assets/platform/darwin-arm64/arduino-cli/arduino-cli.app. Unfortunately, I did not run xattr -l …, so I don't know what that @ was representing. Whatever it was, it was either added as part of the OS upgrade to Sonoma, or is an attribute that Sonoma has a problem with, but the previous OS did not.
• After reinstalling the Extension on Sonoma, the new (working on Sonoma) file permissions were -rwxr-xr-x 1 fredsa primarygroup 27917936 Nov 5 12:43 /Users/fredsa/.vscode/extensions/vsciot-vscode.vscode-arduino-0.6.0-darwin-arm64/assets/platform/darwin-arm64/arduino-cli/arduino-cli.app

Finally, while I don't think @dbmzzo's steps were needed, for completeness sake, I did try those settings first. Here are the steps I actually followed:

1. Granted VS Code access under "Privacy & Security > {Full Disk Access, Developer Tools, App Management}" --> Did not appear to fix anything for me.
2. Uninstalled Arduino extension --> restarted VS code a couple of times --> confirmed ~/.vscode/extensions/vsciot-vscode.vscode-arduino-0.6.0-darwin-arm64 was gone --> reinstalled Arduino extension --> extension immediately started working again
3. Undid the grants for VS Code in "Privacy & Security > {Full Disk Access, Developer Tools, App Management}" --> Uninstalled Arduino extension --> confirmed directory was gone --> reinstalled Arduino extension --> extension was still working

That last step (#3) suggests to me that the "Privacy & Security > {Full Disk Access, Developer Tools, App Management}" settings are not needed, but I could be wrong. It's possible that my machine had two issues: a) the broken extension that needed to be reinstalled on Sonoma, b) VS code needed one-time access to make a change that was granted by the Privacy & Security settings.

I know the original disk access fix worked for the people who needed it on my end. It sounds like you had a different problem.

[JM-FRANCE]

Regarding the @ at the end of the permissions, it’s likely metadata flagging a quarantined file (in this case app downloaded from the web / brought in through a third party app or source) and which drives Gatekeeper’s notifications.

[fredsa]

I know the original disk access fix worked for the people who needed it on my end. It sounds like you had a different problem.

Regarding the @ at the end of the permissions, it’s likely metadata flagging a quarantined file (in this case app downloaded from the web / brought in through a third party app or source) and which drives Gatekeeper’s notifications.

Given the file permissions / file attributes issue I found, and the Privacy & Security settings that worked for others, it would be great if others with this issue tried the following:

1. Capture the broken state:
   • Record the file file permissions / attributes, save the output of:

     ls -l ~/.vscode/extensions/vsciot-vscode.vscode-arduino-*/assets/platform/*/arduino-cli/arduino-cli.app
     xattr -l ~/.vscode/extensions/vsciot-vscode.vscode-arduino-*/assets/platform/*/arduino-cli/arduino-cli.app

2. Note the state of Visual Studio Code's settings:
   • Privacy & Security > Full Disk Access
   • Privacy & Security > Developer Tools
   • Privacy & Security > App Management
3. If the file permissions are not -rwxr-xr-x:
   • Try reinstalling the Arduino extension using above steps 1-6
   • Did that work? Are the file permissions now -rwxr-xr-x?
4. Grant VS Code access as described above steps 1-5
   • Did that work?
   • Did VS code change the file permissions? Are they (still) -rwxr-xr-x?
     5. Ungrant VS Code access, i.e. put the permissions back the way they were
   • Do things still work?

[alfonsocatanzaro]

Hi, I have the same issue after macos update. I've tried to give full disk access to vscode, uninstalla and reinstall extension, without success. When I execute builtin arduino-cli within extension directory I obtain "killed" message. There is any other protection system?

 ~/.vscode/extensions/vsciot-vscode.vscode-arduino-0.6.0-darwin-x64/assets/platform/darwin-x64/arduino-cli 

$ la
total 57488
-rw-r--r--  1 alfonso  staff    34K  7 Nov 21:24 LICENSE.txt
-rwxr-xr-x  1 alfonso  staff    28M  7 Nov 21:24 arduino-cli.app

$ ./arduino-cli.app version
[1]    49607 killed     ./arduino-cli.app version
✘  ~/.vscode/extensions/vsciot-vscode.vscode-arduino-0.6.0-darwin-x64/assets/platform/darwin-x64/arduino-cli

Thank you in advance for help.

[fellow7000]

Faced to the very same issue on Macos 14 yesterday. Interesting, it's not possible to find anything useful using Google search - issue is new and not really known by the search engine. Today I decided to have a look on the open issues here and found it immediately :)

I granted full disk access, add to app management and developer tools, so extension started to work - I could verify and upload my sketch. After that I switched the full disk access off again, restarted the VS Code and it looks like still working.

Will keep the setup for a while. Hope, MS will fix this annoying issue or at leas provide official FAQ for it.

[sergiyd]

As temp solution. Set output folder in your arduino.json, for ex. "output": "./output", create a folder, in Finder click Get Info, unlock in the very bottom, set Read&Write for Everyone, then Apply for enclosed items. Not sure that last one is necessary, but I have already files there after successful built with granted permissions.

UPD After try to build again I'm getting

Error during build: unable to read contents of the source item: open ../output/compile_commands.json: no such file or directory

deleting of this file allows to build. Not quite handy, but maybe will help to solve this issue sooner.

[btmills]

I was able to resolve {"code":null} without touching any permissions.

I have attempted to install the arduino-cli manually on the first student's computer and using the cli directly through a terminal poses no problems. I was unable to configure the arduino extension to use the cli instead of the bundled cli in the time available.

Like @nosknut, I observed that arduino-cli was working correctly. After I configured the VSCode extension to use the separate CLI instead of the bundled CLI, the extension works again.

1. I already had arduino-cli installed via Homebrew.
2. I ran which arduino-cli in my terminal to get its path, which in my case was /usr/local/bin-arduino-cli.
3. I added "arduino.path": "/usr/local/bin" and "arduino.commandPath": "arduino-cli" to .vscode/settings.json.
4. Reload VSCode.
5. Builds successfully again!

[ScreamZ]

I was able to resolve {"code":null} without touching any permissions.

I confirm this works

[andrewk123]

Following on from this.. Note: I did/do not have arduino-cli installed via homebrew or similar.

The permissions issue seems to relate to the file name. The bundled version of the arduino-cli has been renamed to arduino-cli.app. This is what I think is triggering gatekeeper to kill it. To show this try the following:

1. cd ~/.vscode/extensions/vsciot-vscode.vscode-arduino-*/assets/platform/*/arduino-cli/
2. enter ./arduino-cli.app version (you get back - zsh: killed ./arduino-cli.app)
3. cp arduino-cli.app arduino-cli
4. enter ./arduino-cli version (you get back - arduino-cli Version: 0.31.0 Commit: 940c9457 Date: 2023-02-22T16:15:54Z) ie all is working
5. I simply then moved the "new" arduino-cli to /usr/local/bin/ (mv arduino-cli /usr/local/bin/) and added the arduino.path and arduino.commandPath to settings [per @btmills above] and restarted vscode and all then works without any permissions changes and using the bundled arduino-cli (which appears be 7 months behind the current released version of 0.34.2 but is the version the devs have tested with I assume).

I don't view the above as anything like a permanent solution however it did get me going again without any permissions changes that would take more analysis than i want to do right now.

I'm not sure why the devs changed the file name however it seems to be what is driving the issue so I assume it would be easy enough to change it back in the next version of this plugin.

[fredsa]

I've now encountered {"code": null} a number of times on the same machine running Sonoma. Since I've also installed an upgrade to Sonoma a few times, I suspect that this issue is reappearing each time an OS update is installed.

I have reliably been able to fix the issue every time using @dbmzzo's instructions. Specifically:

1. Try "CMD-SHIFT-P > Arduino: Rebuild IntelliSense Configuration", but get {"code": null} output error message.
2. Grant VS Code access 3x under "Privacy & Security > {Full Disk Access, Developer Tools, App Management}"
3. Try "CMD-SHIFT-P > Arduino: Rebuild IntelliSense Configuration", which now works
4. (Undo the permission grants in step 2)

— For completeness, I'll note that this first time I encountered this issue after an upgrade from an earlier OS version to Sonoma, I believe I had the additional problem that Arduino extension was quarantined as @JM-FRANCE suggested, indicated by the @ in the file permissions (-rwxr-xr-x@) when I ran ls -ld ~/.vscode/extensions/vsciot-vscode.vscode-arduino-*. Unfortunately, I did not run xattr -l ~/.vscode/extensions/vsciot-vscode.vscode-arduino-* which would've confirmed this.

[mkumar2789]

I've now encountered {"code": null} a number of times on the same machine running Sonoma. Since I've also installed an upgrade to Sonoma a few times, I suspect that this issue is reappearing each time an OS update is installed.

I have reliably been able to fix the issue every time using @dbmzzo's instructions. Specifically:

1. Try "CMD-SHIFT-P > Arduino: Rebuild IntelliSense Configuration", but get {"code": null} output error message.
2. Grant VS Code access 3x under "Privacy & Security > {Full Disk Access, Developer Tools, App Management}"
3. Try "CMD-SHIFT-P > Arduino: Rebuild IntelliSense Configuration", which now works
4. (Undo the permission grants in step 2)

— For completeness, I'll note that this first time I encountered this issue after an upgrade from an earlier OS version to Sonoma, I believe I had the additional problem that Arduino extension was quarantined as @JM-FRANCE suggested, indicated by the @ in the file permissions (-rwxr-xr-x@) when I ran ls -ld ~/.vscode/extensions/vsciot-vscode.vscode-arduino-*. Unfortunately, I did not run xattr -l ~/.vscode/extensions/vsciot-vscode.vscode-arduino-* which would've confirmed this.

What is the possibility of resolving this issue for macOS Sonoma (M1 MacBook)? And what about PlatformIO for Arduino, What do you think?

[andrewk123]

As I said above, "all" the devs have to do is rename arduino-cli.app to arduino-cli and then change the default name for the Arduino CLI from arduino-cli.app to arduino-cli in the plugin code and all should be good. I assume this would be quick and easy to do for the Devs. If it is not then I would be interested to hear why.

In the meantime, if you want to avoid having to play with permissions after every restart you can just use the combination of @btmills and my formulas mentioned above.

[mahadevParimi]

Go the extensions, search for arduino extension and click on "switch to pre-release version" beside uninstall button and click on "Reload required"

[series8217]

This remains an issue on MacOS. Are there any plans to fix it?

I am curious to hear a dev response to @andrewk123's comment above which looks like the best solution if it works. https://github.com/microsoft/vscode-arduino/issues/1681#issuecomment-1936646817

[toenobu]

I fixed the problem with following https://github.com/microsoft/vscode-arduino/issues/1681#issuecomment-1795449722 .

The version of Auduino extension I've fixed is v0.6.230727001 (pre-release).