starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-04 05:35:20 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Network Injected Azure Cloud Shell Not Supported #20032

New Issue
Open
opened 2026-01-31 07:01:21 +00:00 by claunia · 4 comments
claunia commented 2026-01-31 07:01:21 +00:00
Owner
Copy Link

Originally created by @lsuarez5280 on GitHub (Jun 6, 2023).

Windows Terminal version

1.17.11461.0

Windows build number

10.0.22621.0

Other Software

No response

Steps to reproduce

  1. Configure Cloud Shell with Azure Virtual Network injection according to the documentation. IMPORTANT: Deploy the virtual network in a Cloud Shell primary region to avoid failures, e.g. East US, West US, or South Central US as it seems secondary region support isn't guaranteed for the virtual network injection scenario in other regions.
  2. Open an Azure Cloud Shell tab and perform device code login.
  3. [Optional] Select a tenant from the list displayed by Terminal if appropriate for your account.
  4. Elect whether to save connection settings.
  5. Observe outputs.

Expected Behavior

A terminal prompt.

Actual Behavior

After logging in, selecting a tenant from my account list, and confirming saving connection settings, the terminal immediately displays:

Requesting a cloud shell instance...
Succeeded.
Requesting a terminal (this might take a while)...

[process exited with code 1 (0x00000001)]
You can now close this terminal with Ctrl+D, or press Enter to restart.

Originally created by @lsuarez5280 on GitHub (Jun 6, 2023). ### Windows Terminal version 1.17.11461.0 ### Windows build number 10.0.22621.0 ### Other Software _No response_ ### Steps to reproduce 1. Configure Cloud Shell with Azure Virtual Network injection according to [the documentation](https://learn.microsoft.com/en-us/azure/cloud-shell/private-vnet). **IMPORTANT:** Deploy the virtual network in a Cloud Shell [primary region](https://learn.microsoft.com/en-us/azure/cloud-shell/persisting-shell-storage#supported-storage-regions) to avoid failures, e.g. East US, West US, or South Central US as it seems secondary region support isn't guaranteed for the virtual network injection scenario in other regions. 2. Open an Azure Cloud Shell tab and perform device code login. 3. [Optional] Select a tenant from the list displayed by Terminal if appropriate for your account. 4. Elect whether to save connection settings. 5. Observe outputs. ### Expected Behavior A terminal prompt. ### Actual Behavior After logging in, selecting a tenant from my account list, and confirming saving connection settings, the terminal immediately displays: >Requesting a cloud shell instance... >Succeeded. >Requesting a terminal (this might take a while)... > >[process exited with code 1 (0x00000001)] >You can now close this terminal with Ctrl+D, or press Enter to restart.
claunia added the Issue-BugPriority-3Product-TerminalArea-AzureShell labels 2026-01-31 07:01:21 +00:00
claunia commented 2026-01-31 07:01:22 +00:00
Author
Owner
Copy Link

@lhecker commented on GitHub (Jun 7, 2023):

I personally don't use Azure Cloud Shell, so I'm a little unfamiliar with how it behaves, but when you write:

[process exited with code 1 (0x00000001)]

then that's a message specific to regular, local shells (including ssh). In other words, you're not talking about our built-in "Azure Cloud Shell" profile, right? So, when you write

Attempt to obtain a cloud shell from your tenant using Windows Terminal.

How are you "obtaining a cloud shell" then? After reading the documentation you've linked, I still don't quite understand how one would do that. Do you use some PowerShell commands to create a connection? If so, could you tell us your profile's command line (stripped of anything that's secret of course)?

@lhecker commented on GitHub (Jun 7, 2023): I personally don't use Azure Cloud Shell, so I'm a little unfamiliar with how it behaves, but when you write: > [process exited with code 1 (0x00000001)] then that's a message specific to regular, local shells (including ssh). In other words, you're not talking about our built-in "Azure Cloud Shell" profile, right? So, when you write > Attempt to obtain a cloud shell from your tenant using Windows Terminal. How are you "obtaining a cloud shell" then? After reading the documentation you've linked, I still don't quite understand how one would do that. Do you use some PowerShell commands to create a connection? If so, could you tell us your profile's command line (stripped of anything that's secret of course)?
claunia commented 2026-01-31 07:01:22 +00:00
Author
Owner
Copy Link

@lsuarez5280 commented on GitHub (Jun 7, 2023):

@lhecker this is what you receive when opening an Azure Cloud Shell in terminal.
image

This is what I mean by attempting to obtain a cloud shell. I have no idea how Windows Terminal meaningfully functions, but if I had to guess, it's likely trying to function similarly to the Azure Portal cloud shell by proxying commands for an Azure Container Instance that lives in your Azure Virtual Network. This begins by logging in, selecting your tenant, and if it behaves anything like Portal, likely using Azure resource APIs from the Microsoft.Portal provider (I'd guess) to launch that container and poll for it to start.

To describe how this is done in Portal, this looks something like:

PUT /providers/Microsoft.Portal/consoles/default?api-version=2023-02-01-preview HTTP/1.1
Host: management.azure.com
Content-Type: application/json
Authorization: Bearer [jwt]

{
  "properties": {
    "osType": "linux"
  }
}

...and then transitioning to a periodic GET request on that same resource until the provisioningState property in the response is Succeeded. The response body is similar to the following:

{
  "properties": {
    "osType": "Linux",
    "provisioningState": "Succeeded",
    "uri": "https://gateway12.southcentralus.console.azure.com:443/n/cc-2edbc364/cc-2edbc364"
  }
}

A request is made to the URI provided in the response to identify the running terminal container's web socket interface and indicate window size (I would imagine for stream output formatting):

POST /n/cc-2edbc364/cc-2edbc364/terminals?cols=230&rows=13&version=2019-01-01&shell=pwsh
Host: gateway12.southcentralus.console.azure.com
Content-Type: application/json
Authorization: Bearer [jwt]

{}

And the response provides a URI for the web socket endpoint:

{
    "id": "[guid]",
    "socketUri": "wss://gateway12.southcentralus.console.azure.com/n/cc-2edbc364/cc-2edbc364/terminals/[guid]",
    "idleTimeout": "20",
    "tokenUpdated": true,
    "rootDirectory": "/home/lindsey"
}

The Portal uses that response to open web socket connections and stream commands to the endpoint providing access to cloud shell container using the socketUri returned in that API request, e.g.:

  • wss://gateway12.southcentralus.console.azure.com/$hc/n/cc-2edbc364/cc-2edbc364/terminals/[guid], and
  • wss://gateway12.southcentralus.console.azure.com/$hc/n/cc-2edbc364/cc-2edbc364/terminals/[guid]/control

As far as the full output of my experience in Windows Terminal, it is as follows when attempting to obtain a cloud shell from a tenant where I have configured those containers to be network injected into my Azure Virtual Network:

To sign in, use a web browser to open the page https://microsoft.com/devicelogin and enter the code F4TD22D5B to authenticate.
This code will expire in 15 minutes.
Authenticated.
Tenant 0: Lindsey Suarez - Personal (lsuarezlearn.onmicrosoft.com)
Tenant 1: Corporate ([redacted].onmicrosoft.com)
Tenant 2: Sandbox ([redacted].com)
Tenant 3: Client ([redacted].onmicrosoft.com)
Please enter the desired tenant number.
> 0
Do you want to save these connection settings for future logins? [y/n]
> y
Your connection settings have been saved for future logins.
Requesting a cloud shell instance...
Succeeded.
Requesting a terminal (this might take a while)...

[process exited with code 1 (0x00000001)]
You can now close this terminal with Ctrl+D, or press Enter to restart.

Normal output after selecting a tenant without my cloud shell settings configured for network injection instead looks like this:

To sign in, use a web browser to open the page https://microsoft.com/devicelogin and enter the code FVRCS8MPB to authenticate.
This code will expire in 15 minutes.
Authenticated.
Tenant 0: Lindsey Suarez - Personal (lsuarezlearn.onmicrosoft.com)
Tenant 1: Corporate ([redacted].onmicrosoft.com)
Tenant 2: Sandbox ([redacted].com)
Tenant 3: Client ([redacted].onmicrosoft.com)
Please enter the desired tenant number.
> 2
Do you want to save these connection settings for future logins? [y/n]
> y
Your connection settings have been saved for future logins.
Requesting a cloud shell instance...
Succeeded.
Requesting a terminal (this might take a while)...


MOTD: SqlServer has been updated to Version 22!

VERBOSE: Authenticating to Azure ...
VERBOSE: Building your Azure drive ...
PS /home/lindsey>

The original report has been updated for clarity.

@lsuarez5280 commented on GitHub (Jun 7, 2023): @lhecker this is what you receive when opening an Azure Cloud Shell in terminal. ![image](https://github.com/microsoft/terminal/assets/12800602/439f640b-0911-4b3f-b33d-5c8fe52fab93) This is what I mean by attempting to obtain a cloud shell. I have no idea how Windows Terminal meaningfully functions, but if I had to guess, it's likely trying to function similarly to the Azure Portal cloud shell by proxying commands for an Azure Container Instance that lives in your Azure Virtual Network. This begins by logging in, selecting your tenant, and if it behaves anything like Portal, likely using Azure resource APIs from the Microsoft.Portal provider (I'd guess) to launch that container and poll for it to start. To describe how this is done in Portal, this looks something like: ``` PUT /providers/Microsoft.Portal/consoles/default?api-version=2023-02-01-preview HTTP/1.1 Host: management.azure.com Content-Type: application/json Authorization: Bearer [jwt] { "properties": { "osType": "linux" } } ``` ...and then transitioning to a periodic GET request on that same resource until the `provisioningState` property in the response is `Succeeded`. The response body is similar to the following: ``` { "properties": { "osType": "Linux", "provisioningState": "Succeeded", "uri": "https://gateway12.southcentralus.console.azure.com:443/n/cc-2edbc364/cc-2edbc364" } } ``` A request is made to the URI provided in the response to identify the running terminal container's web socket interface and indicate window size (I would imagine for stream output formatting): ``` POST /n/cc-2edbc364/cc-2edbc364/terminals?cols=230&rows=13&version=2019-01-01&shell=pwsh Host: gateway12.southcentralus.console.azure.com Content-Type: application/json Authorization: Bearer [jwt] {} ``` And the response provides a URI for the web socket endpoint: ``` { "id": "[guid]", "socketUri": "wss://gateway12.southcentralus.console.azure.com/n/cc-2edbc364/cc-2edbc364/terminals/[guid]", "idleTimeout": "20", "tokenUpdated": true, "rootDirectory": "/home/lindsey" } ``` The Portal uses that response to open web socket connections and stream commands to the endpoint providing access to cloud shell container using the socketUri returned in that API request, e.g.: - `wss://gateway12.southcentralus.console.azure.com/$hc/n/cc-2edbc364/cc-2edbc364/terminals/[guid]`, and - `wss://gateway12.southcentralus.console.azure.com/$hc/n/cc-2edbc364/cc-2edbc364/terminals/[guid]/control` --- As far as the full output of my experience in Windows Terminal, it is as follows when attempting to obtain a cloud shell from a tenant where I have configured those containers to be network injected into my Azure Virtual Network: ``` To sign in, use a web browser to open the page https://microsoft.com/devicelogin and enter the code F4TD22D5B to authenticate. This code will expire in 15 minutes. Authenticated. Tenant 0: Lindsey Suarez - Personal (lsuarezlearn.onmicrosoft.com) Tenant 1: Corporate ([redacted].onmicrosoft.com) Tenant 2: Sandbox ([redacted].com) Tenant 3: Client ([redacted].onmicrosoft.com) Please enter the desired tenant number. > 0 Do you want to save these connection settings for future logins? [y/n] > y Your connection settings have been saved for future logins. Requesting a cloud shell instance... Succeeded. Requesting a terminal (this might take a while)... [process exited with code 1 (0x00000001)] You can now close this terminal with Ctrl+D, or press Enter to restart. ``` Normal output after selecting a tenant without my cloud shell settings configured for network injection instead looks like this: ``` To sign in, use a web browser to open the page https://microsoft.com/devicelogin and enter the code FVRCS8MPB to authenticate. This code will expire in 15 minutes. Authenticated. Tenant 0: Lindsey Suarez - Personal (lsuarezlearn.onmicrosoft.com) Tenant 1: Corporate ([redacted].onmicrosoft.com) Tenant 2: Sandbox ([redacted].com) Tenant 3: Client ([redacted].onmicrosoft.com) Please enter the desired tenant number. > 2 Do you want to save these connection settings for future logins? [y/n] > y Your connection settings have been saved for future logins. Requesting a cloud shell instance... Succeeded. Requesting a terminal (this might take a while)... MOTD: SqlServer has been updated to Version 22! VERBOSE: Authenticating to Azure ... VERBOSE: Building your Azure drive ... PS /home/lindsey> ``` The original report has been updated for clarity.
claunia commented 2026-01-31 07:01:23 +00:00
Author
Owner
Copy Link

@JoeyC-Dev commented on GitHub (Sep 4, 2023):

You may want to check with Cloud shell web version, which may give you more detailed error message.

One possible reason is that your fileshare which was mounted to cloud shell is unmounted. If this is the case, then:
https://learn.microsoft.com/en-us/azure/cloud-shell/persisting-shell-storage#the-clouddrive-mount-command

It is possible that this has nothing to do with Terminal.

Update: The reason I comment this is because that I faced the same issue, and eventually find out there is something wrong about the fileshare. You may want to "remove the saved connection settings" and then re-login in Terminal after solving the issue. To check if the issue gets solved, try using Cloud Shell web version.

@JoeyC-Dev commented on GitHub (Sep 4, 2023): You may want to check with Cloud shell web version, which may give you more detailed error message. One possible reason is that your fileshare which was mounted to cloud shell is unmounted. If this is the case, then: https://learn.microsoft.com/en-us/azure/cloud-shell/persisting-shell-storage#the-clouddrive-mount-command It is possible that this has nothing to do with Terminal. --- Update: The reason I comment this is because that I faced the same issue, and eventually find out there is something wrong about the fileshare. You may want to "remove the saved connection settings" and then re-login in Terminal after solving the issue. To check if the issue gets solved, try using Cloud Shell web version.
claunia commented 2026-01-31 07:01:23 +00:00
Author
Owner
Copy Link

@lsuarez5280 commented on GitHub (Sep 6, 2023):

@JoeyC-Dev Thank you for the suggestion. However, the network injected cloud shell works normally via the web interface.

@lsuarez5280 commented on GitHub (Sep 6, 2023): @JoeyC-Dev Thank you for the suggestion. However, the network injected cloud shell works normally via the web interface.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Area-AzureShell Issue-Bug Priority-3 Product-Terminal
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#20032
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?