Change:
VS Code Version: Version: 1.86.1 Commit: Date: 2024-02-07T09:08:57.920Z Electron: 27.2.3 ElectronBuildId: Chromium: 118.0.5993.159 18.17.1 V8: 11.8.172.18-electron.0 OS: Darwin arm64 23.3.0 Steps to Reproduce: a dev container that has the feature, like for (but I have replicated with all azd my dev containers) the username to login as it redirects to localhost, you'll see that the localhost does not exist. on that URL inside VS Code, and you'll see it does exist there, indicating that port forwarding failed. I've also tried to replicate it in Insiders, but there I'm getting a different error with SSL. I am going to CC to comment about how azd implements its local server, to see if that sheds light on why port forwarding is not working reliably. Note that this did work for a long time, and only started failing in last few months.
azd uses to implement the OAuth2.0 protocol for logging in. As part of the process, a simple HTTP server in localhost to wait for the login response. As soon as the server start listening, VSCode is expected to automatically create a port-forward to the port used by the http-server. This behavior is seen on Windows and Linux, when running VSCode desktop client connected to a devcontainer, but somehow, the port-forwarding is not happening since a few days ago for macOS. When moving back to an older VSCode version for macOS, we can see the expected behavior, which makes this looks like a possible VSCode regression... I don't know if it is VSCode desktop client or vscode-remote-extension what is responsible of creating the port-forwarding. Is there a way to see logs for whatever is handling that?
Can you share the value of the setting ?
My user setting contains this: "remote.autoForwardPortsSource": "hybrid",
Can you also share the value of ? And finally, how many ports do you have forwarded?
Hm, that setting is not defined in my User Settings JSON, so I assume it's the default values. My devcontainer only specifies a single port for forwarding, , and that's all that's currently showing up in the Ports tab. Also, btw, in a thread with Oswaldo, it was suggested I try the Codespaces extension in my local VS Code, and that seems to have same issue.
I think you probably hit our port discovery fallback. Is it possible that you at some point had 20 ports that were auto forwarded? Or did you set manually? I expect that setting will resolve your issue. If you didn't set yourself, then you can disable the fallback with .
Oh I most definitely had more than 20 ports at one point. I don't recall what process was responsible, but my ports tab had dozens of ports. I re-built the container at that point in case that was the problem. But if just getting to that state triggers a permanent setting change to "hybrid", then that would explain the issue. So should I set it to "process" or set the fallback to 0 at this point?
yes, that should get the behavior you want back. We show a notification when the fallback threshold is hit, but you might have missed it due to notification fatigue. Maybe we need a better way to show that threshold has been hit.
Okay great, that does seem to work! CC who was experiencing the same.
I've hit this problem quite a bit recently and the most perplexing thing about the situation is that even though I've set "remote.autoForwardPortsSource" to "process" in my , VSCode doesn't respect it. If VSCode is just going to ignore a setting that I've manually set, why bother giving me the ability to change it?
VS Code should be respecting . Maybe the setting is overridden in your workspace or folder settings.
Unfortunately it is not. As you can see from the screenshot, it is not respecting it and it tells me that it has been overridden. I've also the to my but it's been commented out. I feel that I shouldn't have to set this setting to "0" to make stick. !
I just got it again today too. I think most of the forwarded ports were from "Code extension host", not ones I forwarded. I only knew to "Undo" because of this thread. I'm concerned that developers are getting this setting changed on them and suffering unexpected consequences. <img width="469" alt="Screenshot 2024-03-13 at 6 03 08 AM" src=""
Proposed new behavior: When has been configured, it is respected When has been configured as and hasn't been configured, then will be treated as though it's set to 0.
<!-- AUTHORVERIFICATIONREQUEST --This bug has been fixed in the latest release of ! you can help us out by commenting if things are now working as expected. If things still don't seem right, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
can we get some verification steps just in case?
Original steps LGTM now!

Discussion:
} } <ins> private getPortAutoFallbackNumber(): number { const fallbackAt = this.configurationService.inspect<number>(PORT_AUTO_FALLBACK_SETTING); if ((fallbackAt.value !== undefined) && (fallbackAt.value === 0 || (fallbackAt.value !== fallbackAt.defaultValue))) { return fallbackAt.value; } const inspectSource = this.configurationService.inspect(PORT_AUTO_SOURCE_SETTING); if (inspectSource.applicationValue === PORT_AUTO_SOURCE_SETTING_PROCESS || inspectSource.userValue === PORT_AUTO_SOURCE_SETTING_PROCESS || inspectSource.userLocalValue === PORT_AUTO_SOURCE_SETTING_PROCESS || inspectSource.userRemoteValue === PORT_AUTO_SOURCE_SETTING_PROCESS || inspectSource.workspaceFolderValue === PORT_AUTO_SOURCE_SETTING_PROCESS || inspectSource.workspaceValue === PORT_AUTO_SOURCE_SETTING_PROCESS) { return 0; } return fallbackAt.value ?? 20; } </ins> private listenForPorts() { <del> let fallbackAt = this.configurationService.getValue<number>(PORT_AUTO_FALLBACK_SETTING); </del> <ins> let fallbackAt = this.getPortAutoFallbackNumber(); </ins> if (fallbackAt === 0) { this.portListener?.dispose(); return;

if (this.procForwarder && !this.portListener && (this.configurationService.getValue(PORT_AUTO_SOURCE_SETTING) === PORT_AUTO_SOURCE_SETTING_PROCESS)) { this.portListener = this._register(this.remoteExplorerService.tunnelModel.onForwardPort(async () => { <del> fallbackAt = this.configurationService.getValue<number>(PORT_AUTO_FALLBACK_SETTING); </del> <ins> fallbackAt = this.getPortAutoFallbackNumber(); </ins> if (fallbackAt === 0) { this.portListener?.dispose(); return;

'remote.autoForwardPortsFallback': { type: 'number', default: 20, <del> markdownDescription: localize('remote.autoForwardPortFallback', "The number of auto forwarded ports that will trigger the switch from `process` to `hybrid` when automatically forwarding ports and `remote.autoForwardPortsSource` is set to `process`. Set to `0` to disable the fallback.") </del> <ins> markdownDescription: localize('remote.autoForwardPortFallback', "The number of auto forwarded ports that will trigger the switch from `process` to `hybrid` when automatically forwarding ports and `remote.autoForwardPortsSource` is set to `process` by default. Set to `0` to disable the fallback. When `remote.autoForwardPortsFallback` hasn't been configured, but `remote.autoForwardPortsSource` has, `remote.autoForwardPortsFallback` will be treated as though it's set to `0`.") </ins> }, 'remote.forwardOnOpen': { type: 'boolean',