VS Code Terminal is running using Rosetta 2 on Apple M1

[gabimoncha]

• VS Code Version: 1.54.0-insider
  Commit: a699ffa
• OS Version: macOS Big Sur 11.2.1 (20D74) on Mac mini m1

Steps to Reproduce:

1. Open VS Code Terminal
2. Type arch in VS Code Terminal

The expected output should be arm64 the same as when you type arch in the standalone Terminal.

Does this issue occur when all extensions are disabled?: Yes/No
Yes

[Adam2Marsh]

Are there any updates on this issue? Lost a couple of weeks when I didn't realise the terminal was running in the wrong arch.

Thanks.

[guilhermeKodama]

I have a similar issue but I want to accomplish the opposite. I want vscode to use the terminal with Rosetta on and not off

[gabimoncha]

Then this is the wrong issue. Have you tried opening VS Code with Rosetta?

[mikehardy]

Noticed this myself - this is important because some things can't compile yet on apple silicon (e.g., react-native-google-signin/google-signin#948) so at least temporarily I need to #ifndef __arm64__ out chunks of code while building an iOS app.

As long as VSCode Terminal is running under Rosetta 2 it means I can't compile from inside VSCode easily (the symbol is not defined, and then the compile fails) - compiling in Terminal outside VSCode works.

[jersearls]

Anyone have a solution to this? Is there a setting in VScode to not emulate x86 in the terminal?

[prakashcc]

@jersearls @mikehardy @gabrielmoncea

This issue is related to system app changes not related to vscode terminal because vscode is using the default system terminal and we can change it also.

Steps to resolve -

1.)Do a cmd + shift + A . It will open Application in finder.
2.) find the terminal app or item app depend on your vscode setting.

3.) right click on terminal and click on get info -> click open using rosetta.

Let me know if this works for you.

[mikehardy]

Hi there - I am certain my Terminal is not by default in Rosetta, I mentioned specifically " compiling in Terminal outside VSCode works". I'll double-check next time I'm near my partner's M1 machine and can check, but my detected problem is that VSCode's internal terminal is in rosetta, but a terminal opened directly is M1-native / non-Rosetta.

[prakashcc]

@michaelchiche by default open using Rosetta is not check so vscode is not taking that into consideration as we select that, it will work perfectly fine.

[mikehardy]

@prakashcc I don't believe we are communicating well. The point of the issue is to get VSCode terminal to NOT open in Rosetta. We want an arm64 terminal inside VSCode. I cannot understand how altering our terminal do be in rosetta will fix our issue. It seems it will make it worse, as then our regular (non VSCode) terminals will also be in Rosetta, which is specifically unwanted.

I do not want Rosetta in use anywhere, ever. I want native arm64 to work, inside and outside of VSCode. That's the bug.

[CactusQ]

You may have downloaded the Intel Chip instead of the Apple Silicon version of VSCode.

Watch the buttons below the huge Apple logo on:

https://code.visualstudio.com/Download

I have tested both versions on my M1 Macbook Air. The Intel chip one yields the i386 terminal by default, the Apple Silicon one the arm64.
This is unrelated to whether you open the "Terminal" application with Rosetta or not. Also, macOS won't let me open VSCode with Rosetta on both cases (Intel / Apple Silicon).

[mikehardy]

@CactusQ very interesting! I'll have to test that out next time I have a timeslice on the M1 machine in our household, thanks for pointer

[prakashcc]

@CactusQ I have tested it on mac m1 and I had installed the m1 setup only but I am able to see the same bug. I tried to find some resolution.

I execute the command in the terminal and it starts using arm64.
env /usr/bin/arch -arm64 /bin/zsh --login

[CactusQ]

I have tested it again (hoping to reproduce the error), but I am sorry I cannot give you any new insights.
You may check that VSCode is recognized as an Intel application (Right-click -> Get Info -> Kind).

Maybe it is a matter of macOS version?

I have attached a screenshot with all info regarding my test setup.

On the left are the specs that are given by the Intel Chip application (VSCode-darwin.zip),
on the right are the ones for the explicit Apple Silicon package (VSCode-darwin-arm64zip).

IIRC I haven't changed anything regarding VSCode, basically using its default settings and typing 'arch' inside the respective terminals (bash by default). Outputs are arm64 and i386 respectively. I have also tried to disable "open with Rosetta" for the standard macOS "Terminal" application but the outcome is the same.

[mikehardy]

@CactusQ I think I may have gotten us closer to understanding with some testing today. I believe (subject to reproduction) that the problem is when I use VSCode on my intel machine (linux or mac) to SSH-Remote to the shared arm64 machine in our house. The terminal is x86-64 for me in that case. I wonder if the remote-ssh darwin binaries have an arm64 option and/or are set up to download correctly on arm64 machines coming from a remote? 🤔

[mikehardy]

@prakashcc

env /usr/bin/arch -arm64 /bin/zsh --login

This is a great workaround and a help to me, thank you! Obvious in hindsight but I didn't think of it

[mikehardy]

Okay: confirmed that with the arm64 VSCode installed locally on an M1 machine, the Terminal is arm64 like you would expect. This is good. However! Confirmed that if you use Remote-SSH to open a session from VSCode running on an intel machine (in my case, Ubuntu Linux) to an M1 machine you get an i386 terminal on the M1 machine.

So it appears that whatever logic is involved in determining the Remote-SSH architecture to download has an issue and does not get arm64 binaries.

That appears to be already logged in the remote-specific repo here, and it is pending an update to the base electron version used, so that node 16 comes in, which has arm64 binaries - microsoft/vscode-remote-release#4069 (comment)

So, I think this is probably close-able:

1. make sure you have the arm64 VSCode and are running locally - or -
2. if connecting to an M1 machine remotely, wait for a fix to the issue above or specifically exec a shell via arch arm64

[Atchett]

This may, or may not, be of any use. Using a MacBook Air M1.

I need to have Node 14.x.x installed for some of the stuff I am working on and later versions of Node for other stuff. I use nvm to install different versions of Node.

I found that I needed to have a Rosetta 2 enabled copy of my terminal to allow me to install Node 14 with nvm (I tried in a non-Rosetta 2 terminal and it didn't work correctly). Create a copy of the terminal in apps, name it terminal rosetta (or whatever you like), then go to info and enable Rosetta.

So, for the Node 14 dev stuff I open the Rosetta enabled Terminal, navigate to the code and "code ." this opens the source and the terminal is i386 (using "arch" command).

For other Node dev stuff (later versions) I use the "normal" terminal (non rosetta), navigate to the code, "code ." and it opens source and the terminal is arm64 (using "arch" command).

I am using the Apple Silicon version of VS Code and if I open it directly then it defaults to arm64.

Like I say, might be completely useless information but if it helps someone then great.

[mikehardy]

I do not use Rosetta for anything, I use nvm to install node, I use node v14 🤔

[mike@yv ~]$ arch
arm64
[mike@yv ~]$ nvm list
->     v14.17.6
default -> v14 (-> v14.17.6)
iojs -> N/A (default)
unstable -> N/A (default)
node -> stable (-> v14.17.6) (default)
stable -> 14.17 (-> v14.17.6) (default)
lts/* -> lts/fermium (-> v14.17.6)
lts/argon -> v4.9.1 (-> N/A)
lts/boron -> v6.17.1 (-> N/A)
lts/carbon -> v8.17.0 (-> N/A)
lts/dubnium -> v10.24.1 (-> N/A)
lts/erbium -> v12.22.6 (-> N/A)
lts/fermium -> v14.17.6
[mike@yv ~]$ which node
/Users/mike/.nvm/versions/node/v14.17.6/bin/node
[mike@yv ~]$ node --version
v14.17.6
[mike@yv ~]$ node -p "process.arch"
arm64

Just for grins since I see v14.18.0 is out I did nvm install v14.18.0 in that same terminal session (arm64). Worked fine? I checked and I'm using Xcode 13.0 in that Terminal as well for what it's worth.

I'd check your local setup @Atchett

At this point I have arm64 Terminals inside VS Code when I'm on the actual machine locally. It's the vscode remote that is the only problem for me.

[Atchett]

Grins indeed @mikehardy, this stuff is always fun...

Just to follow up, I had tried the nvm install 14 (not specifying version, just the latest) using an arm64 terminal session. This worked, although it downloaded the code and compiled on the fly (ref - https://www.youtube.com/watch?v=g-JmtyYiMnM) so it took forever!

Once Node 14 was installed, without issue, I then tried the rest of the setup (the SPFx Yeoman generator) and this was the stuff that started to fail. I suspect that it is trying to compile some libraries / modules and the link, that aren't M1 compatible as yet (a whole bunch of gyp errors).

I removed the 14 install, went through the same process using a Rosetta enabled terminal and it worked. This was when I had the feeling that I would have an issue with VSCode terminals, so did a bit of searching, tried a few things, found this GH issue and reported back here with the view to it hopefully helping someone (granted it might not solve your particular issue).

I hear what you are saying about the remote terminals. Frustrating for you.

I wish you the best of luck in resolving and if I see anything relevant on my web travels I will report back here.

[mikehardy]

That makes sense re SPFx Yeoman not working, I've found most machine learning toolchains aren't M1-compatible either and must use Rosetta (or just an Intel mac), but at least as far as I can see (and from what you saw until you bumped up on SPFx issues) VSCode is doing fine re: arm64 locally in terminals

So I think this issue at least is probably closable

[Tyriar]

@deepak1556 passing over to you as I can't action anything related to apple silicon due to lack of hardware.

[deepak1556]

@Tyriar there is nothing actionable for local install of VSCode, if arm or universal version of VSCode is used then the integrated terminal will not run on Rosetta.

The only issue pending is for Remote-SSH scenario which is tracked in microsoft/vscode-remote-release#4069 (comment)

[notnmeyer]

To hopefully save some folks the entire read:

If the arch inside vscode's terminal is different from the terminal outside, you likely need to install either the universal or apple silicon build of vscode. Things will look like you expect after.

[mikehardy]

Exactly that! The classic cause is restoring from TimeMachine from an Intel mac to an M1 mac. Just had this happen to a colleague 2 days ago. Download + install the arm64 native VSCode, problem solved

[PabloLION]

You may have downloaded the Intel Chip instead of the Apple Silicon version of VSCode.

Watch the buttons below the huge Apple logo on:

https://code.visualstudio.com/Download

I have tested both versions on my M1 Macbook Air. The Intel chip one yields the i386 terminal by default, the Apple Silicon one the arm64. This is unrelated to whether you open the "Terminal" application with Rosetta or not. Also, macOS won't let me open VSCode with Rosetta on both cases (Intel / Apple Silicon).

This solved my problem although I didn't download in the specified page.
Instead, I did in on the "Download" section of index page and thought there was no arm64 version.