You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
feat: list controllers one per line, and name the viewer per setting
Applies the per-line rendering to the controller list too, so the two
reports list principals the same way throughout:
Controllers:
controller: 2vxsx-fae
...
Log visibility: Allowed viewers
log viewer: aaaaa-aa
Status visibility: Allowed viewers
status viewer: 2vxsx-fae
`format_principal_list` holds the shared shape — sorted, one entry per
line, nested two spaces past the label, with a note where the entries
would have gone when the list is empty. Controllers were not sorted
before; they are now, since the replica does not promise an order.
Each entry names what it grants rather than a bare `viewer:`, because a
report carries a line for both visibility settings and the entries under
them would otherwise not say which they belong to.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QooMLZ15EWRrknWtXfFZNp
Copy file name to clipboardExpand all lines: CHANGELOG.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -10,7 +10,7 @@ air-gapped signing
10
10
11
11
* feat: a canister can now declare `upgrade_args` alongside `init_args`, in its own manifest and as a per-canister environment override. It is passed when `icp deploy` upgrades the canister, where `init_args` is passed when it installs or reinstalls it. It takes exactly the forms `init_args` does (inline Candid string, or `{ value | path, format }`), and paths resolve against the canister's own directory the same way. A canister that declares no `upgrade_args` is upgraded with its `init_args`, as before, and `--args` / `--args-file` still override whichever applies.
12
12
* feat: a new `status_visibility` canister setting controls who may read a canister's status (its running state, cycles, memory usage, and settings) through the management canister. It takes the same forms as `log_visibility` — `controllers` (the default), `public`, or `{ allowed_viewers: [...] }` — and can be set in a manifest's `settings:` block or with `icp canister settings update --status-visibility / --add-status-viewer / --remove-status-viewer / --set-status-viewer`. `icp canister status` and `icp canister settings show` now report it. See the [canister settings reference](docs/reference/canister-settings.md#status_visibility).
13
-
*`icp canister status` and `icp canister settings show` now list allowed viewers one per line under the setting (`viewer:<principal>`) rather than comma-separated on the label's line. This applies to `log_visibility` as well, so scripts matching that line need updating.
13
+
*`icp canister status` and `icp canister settings show` now list principals one per line under their label rather than comma-separated on the label's line: `log viewer:` / `status viewer: <principal>` for the allowed viewers of a visibility setting, `controller: <principal>` for a canister's controllers. This applies to `log_visibility`and to the controller list as well, so scripts matching those lines need updating. Both lists are sorted, which the controller list previously was not.
14
14
* This raises the minimum replica version: reading a canister's status now requires one that reports `status_visibility`, and against an older replica `canister_status` fails to decode — which affects `icp deploy`, `icp canister status`, and `icp canister settings show`/`sync`, not just the new setting. Every mainnet subnet reports it. A `managed` network resolves the launcher to `latest` unless it pins `version:`, so only a pinned launcher older than `15.0.0-2026-08-13-03-55` is affected; raise the pin to that version or later.
15
15
* feat: `script` build steps now receive `ICP_CLI_ENVIRONMENT`, the name of the environment the canisters are being built for, so a build can vary by environment the way a sync step already could.
16
16
* feat: `icp completions <SHELL>` prints a shell completion script for `bash`, `zsh`, `fish`, `powershell`, or `elvish` to stdout. See the [installation guide](docs/guides/installation.md#shell-completions) for where to put it.
0 commit comments