Expected Behaviour
When a CLI command resolves an Adobe org from config, it should work consistently regardless of where the command is run.
For aio runtime ip-list get, the command should either:
use an org that is available to the current IMS login, or
detect when the resolved org is not available to the current IMS login and return a clear, actionable error.
This should work whether the org is resolved from global config, local .aio config, or any other supported config source.
Actual Behaviour
aio runtime ip-list get can resolve an org from saved CLI config that does not match the current IMS login.
For example, after switching accounts/orgs with aio login -f, aio console org list may show the orgs available to the new login, but aio config get console.org.code may still point to an org from a previous session.
If aio runtime ip-list get uses that stale org value, the IP list service returns 403 because the current IMS token does not have access to the resolved org.
This is not limited to running from an empty directory. That is just one scenario where the issue is easy to reproduce because there is no local .aio config, so the command falls back to the global selected org. The same class of issue can happen any time the resolved org does not match the current IMS login.
Reproduce Scenario (including but not limited to)
This can happen when switching between Adobe accounts/orgs and the saved org selection is not updated to match the current login.
Steps to Reproduce
-
Log in with an Adobe account/org: - aio login
-
Confirm the saved org: - aio config get console.org.code
-
Log in again with a different Adobe account/org: - aio login -f
-
Confirm the orgs available to the current login: - aio console org list
-
Run the Runtime IP list command from any location where the command resolves the stale org: aio runtime ip-list get
See the 403
Run aio config get console.org.code - Still shows the stage orgID
Environment Info
System:
OS: macOS 15.0.1
CPU: (10) arm64 Apple M1 Max
Memory: 69.72 MB / 32.00 GB
Shell: 3.2.57 - /bin/bash
Binaries:
Node: 24.11.1 - /Users/dthampy/.nvm/versions/node/v24.11.1/bin/node
Yarn: 1.22.19 - /usr/local/bin/yarn
npm: 11.6.2 - /Users/dthampy/.nvm/versions/node/v24.11.1/bin/npm
Virtualization:
Docker: 29.2.1 - /usr/local/bin/docker
npmGlobalPackages:
@adobe/aio-cli: 11.1.0
Additional Context
Additional Context
The core issue is that the command can resolve an org from saved config that is stale relative to the current IMS login.
Running from an empty directory is one reproduction path because the command falls back to the global console.org.code. However, the fix should account for all config-resolution paths and should not assume this only happens when there is no local .aio file.
A clearer user-facing diagnostic could be:
Unable to fetch Runtime egress IPs for the selected Adobe org.
The CLI resolved org , but the current IMS login does not appear to have access to that org.
Run aio console org list to see the orgs available to the current login, then update the selected org and retry:
aio runtime ip-list get
A possible fix could be to make login/org selection update the saved selected org consistently, or have aio runtime ip-list get validate the resolved org against the current login before calling the service.
Expected Behaviour
When a CLI command resolves an Adobe org from config, it should work consistently regardless of where the command is run.
For aio runtime ip-list get, the command should either:
use an org that is available to the current IMS login, or
detect when the resolved org is not available to the current IMS login and return a clear, actionable error.
This should work whether the org is resolved from global config, local .aio config, or any other supported config source.
Actual Behaviour
aio runtime ip-list get can resolve an org from saved CLI config that does not match the current IMS login.
For example, after switching accounts/orgs with aio login -f, aio console org list may show the orgs available to the new login, but aio config get console.org.code may still point to an org from a previous session.
If aio runtime ip-list get uses that stale org value, the IP list service returns 403 because the current IMS token does not have access to the resolved org.
This is not limited to running from an empty directory. That is just one scenario where the issue is easy to reproduce because there is no local .aio config, so the command falls back to the global selected org. The same class of issue can happen any time the resolved org does not match the current IMS login.
Reproduce Scenario (including but not limited to)
This can happen when switching between Adobe accounts/orgs and the saved org selection is not updated to match the current login.
Steps to Reproduce
Log in with an Adobe account/org: - aio login
Confirm the saved org: - aio config get console.org.code
Log in again with a different Adobe account/org: - aio login -f
Confirm the orgs available to the current login: - aio console org list
Run the Runtime IP list command from any location where the command resolves the stale org: aio runtime ip-list get
See the 403
Run aio config get console.org.code - Still shows the stage orgID
Environment Info
Additional Context
Additional Context
The core issue is that the command can resolve an org from saved config that is stale relative to the current IMS login.
Running from an empty directory is one reproduction path because the command falls back to the global console.org.code. However, the fix should account for all config-resolution paths and should not assume this only happens when there is no local .aio file.
A clearer user-facing diagnostic could be:
Unable to fetch Runtime egress IPs for the selected Adobe org.
The CLI resolved org , but the current IMS login does not appear to have access to that org.
Run
aio console org listto see the orgs available to the current login, then update the selected org and retry:aio runtime ip-list get
A possible fix could be to make login/org selection update the saved selected org consistently, or have aio runtime ip-list get validate the resolved org against the current login before calling the service.