Skip to content

Persisting connection information

After logging in to Office 365, the Office 365 CLI will persist the information about the connection until you explicitly log out from Office 365.

Why is persisting connection information important

Persisting connection information is important for two reasons.


First of all it's more convenient to use the Office 365 CLI. If you're using it often to manage a specific tenant, you can connect once and the CLI will remember your credentials. The next time you start the CLI, you can directly start managing your tenant without having to authenticate first.

Building scripts

Additionally, it makes it possible for you to write scripts that automate management of your tenant. When the Office 365 CLI is run in immersive (interactive) mode, the connection information is persisted in memory and is available to all commands run in the CLI command prompt. Unfortunately, one limitation of the immersive mode is that you can only run one command at a time and can't pass the output of one command into another.

When running in the non-immersive (non-interactive) mode, each command is executed in an isolated context and has no access to the memory of any command executed before. So unless you would store the connection information in a variable and explicitly pass it to each command, the CLI would be unable to log in to your tenant. As you can imagine, working with the CLI in this way would be tedious and inconvenient.

By persisting the connection information the Office 365 CLI can be used to build scripts, for example:

Deploy all apps that are not yet deployed in the tenant app catalog:

# get all apps available in the tenant app catalog
apps=$(o365 spo app list -o json)

# get IDs of all apps that are not deployed
notDeployedAppsIds=($(echo $apps | jq -r '.[] | select(.Deployed == false) | {ID} | .[]'))

# deploy all not deployed apps
for appId in $notDeployedAppsIds; do
  o365 spo app deploy -i $appId

First, you use the Office 365 CLI to get the list of all apps from the tenant app catalog using the spo app list command. You set the output type to JSON and store it in a shell variable apps. Next, you parse the JSON string using jq and get IDs of apps that are not deployed. Finally, for each ID you run the spo app deploy Office 365 CLI command passing the ID as a command argument. Notice, that in the script, both spo commands are run as separate commands directly in the shell. In both cases, the shell starts the CLI, executes the specified command and closes the CLI removing all of its resources from memory. Scripts, like the one mentioned above can work, because the Office 365 CLI persists its connection information.

Persisting connection information in Office 365 CLI

When you log in to Office 365 in the Office 365 CLI, the CLI will persist the information about the connection for future reuse. For the established connection, the Office 365 CLI persists the refresh token as well as all access tokens obtained when using the different CLI commands.

Depending on the Office 365 CLI commands you have used, the CLI might persist some additional information. For example, when using commands that interact with SharePoint Online, the CLI will store the URL of your SharePoint Online tenant as well as its ID.

Where the connection information is persisted, depends on the operating system that you are using.


On the macOS, the Office 365 CLI persists its connection information in the system Keychain as a generic credential. You can view what information is stored by opening Keychain Access and searching for Office 365 CLI.


On Windows, the Office 365 CLI persists its connection information in the Windows Credential Manager. To view the persisted credentials, from the Control Panel, navigate to User Accounts and from the Credential Manager section open Manage Windows Credentials. Credentials stored by the Office 365 CLI will be listed in the Generic Credentials section named as Office365Cli--x-y, for example Office365Cli--1-3. Because there is a limit how long a password stored in the Windows Credential Manager can be, connection information stored by the Office 365 CLI will often be split over multiple chunks, where the last two number in the chunk specify the number of chunk and the total number of chunks.


On Linux, the Office 365 CLI stores its connection information in a JSON file located at ~/.o365cli-tokens.json. The contents of this file are not encrypted. The primary use case for supporting Linux operating system is to use the Office 365 CLI in Docker containers, where the tokens file is persisted in the container as long as the container is running. When the container is closed and removed, the file is removed as well. When you would start the container again, you would have to log in to Office 365 first, before you could use the Office 365 CLI.

Removing persisted connection information

Office 365 CLI persists its connection information until you either explicitly log out from the particular service or manually remove the stored credentials.

To check if you are logged in to Office 365 in the Office 365 CLI, run the status command. If you are logged in, the command will return the name of the user account or AAD application used to log in. If you are not connected, the command will return false.

To log out from Office, run the logout command. Running this command will remove all previously stored connection data from your machine.