v0.11.0

Highlights

• client-workflow fix-album-dates: scans albums named after a date (yyyy-MM-dd <title> e.g. 2025-07-04 Garten, or yyyy <title> e.g. 2010 USA), flags assets whose local capture date falls outside the range implied by the album name, and offers to fix exact-day mismatches (only the date changes, time of day is preserved). Supports --dry-run, --offset-days (absorbs camera timezone/DST boundary slack), --interactive (review and fix one album at a time), and --yes. Also adds assets update, exposing the underlying PUT /assets/{id} (updateAsset) as a plain command.
• client-workflow find-heic-tile-defect: detects HEIC/HEIF assets affected by a real Immich thumbnail-rendering defect — files whose pixel width/height aren't an exact multiple of the HEIF grid tile size (512px default) can render as a garbled, low-detail preview/thumbnail even though the original image is completely intact. Read-only by default; --apply-tag optionally tags candidates (default tag immich-admin-cli/corrupt-heic, auto-created) so they can be found again in the web UI.

What's Changed

• Add client-workflow fix-album-dates by @dhcgn in #24
• Add client-workflow find-heic-tile-defect by @dhcgn in #25
• Release v0.11.0 by @dhcgn in #26

Full Changelog: v0.10.0...v0.11.0

v0.10.0

What's Changed

• feat: implement self-update command for immich-admin by @dhcgn in #22
• Self-Update Feature by @dhcgn in #23

Full Changelog: v0.9.0...v0.10.0

v0.10.0-beta.27

What's Changed

• feat: implement self-update command for immich-admin by @dhcgn in #22
• Self-Update Feature by @dhcgn in #23

Full Changelog: v0.9.0...v0.10.0-beta.27

v0.10.0-beta.26

What's Changed

• feat: implement self-update command for immich-admin by @dhcgn in #22
• Self-Update Feature by @dhcgn in #23

Full Changelog: v0.9.0...v0.10.0-beta.26

v0.9.0

What's Changed

New client workflow to bulk-share albums with a user by name pattern, plus the underlying API commands it's built on.

New commands

• albums list (GET /albums) / albums get (GET /albums/{id}, shows current members)
• users list (GET /users) / users get (GET /users/{id})
• client-workflow add-users-to-album-with-pattern (alias cw):
  • Resolves --user to exactly one person (exact UUID, or a case-insensitive substring match on name/email) — errors out and lists candidates if the query is ambiguous or matches nobody
  • Fetches all albums and filters by --include/--exclude regex on album name
  • Previews every matched album (ID, name, asset count), flagging any where the user already has access
  • Confirms via one bulk yes/no, or with --interactive/-i, once per album
  • Shares the confirmed albums at --role (default viewer), skipping albums the user already has access to

Example

# Share every album whose name contains "Amy" or "Amelia" with Julia, deciding album-by-album
immich-admin client-workflow add-users-to-album-with-pattern --include "Amy|Amelia" --user Julia --interactive

Pull requests

• Add client-workflow to bulk-share albums with a user by name pattern by @dhcgn in #20
• Release v0.9.0 by @dhcgn in #21

Full Changelog: v0.8.0...v0.9.0

v0.9.0-beta.24

What's Changed

• Add client-workflow to bulk-share albums with a user by name pattern by @dhcgn in #20
• Release v0.9.0 by @dhcgn in #21

Full Changelog: v0.8.0...v0.9.0-beta.24

v0.8.0

What's Changed

• Release v0.8.0 by @dhcgn in #18

Full Changelog: v0.7.0...v0.8.0

v0.8.0-beta.22

What's Changed

New client workflow to bulk-share albums with a user by name pattern, plus the underlying API commands it's built on.

New commands

• albums list (GET /albums) / albums get (GET /albums/{id}, shows current members)
• users list (GET /users) / users get (GET /users/{id})
• client-workflow add-users-to-album-with-pattern (alias cw):
  • Resolves --user to exactly one person (exact UUID, or a case-insensitive substring match on name/email) — errors out and lists candidates if the query is ambiguous or matches nobody
  • Fetches all albums and filters by --include/--exclude regex on album name
  • Previews every matched album (ID, name, asset count), flagging any where the user already has access
  • Confirms via one bulk yes/no, or with the new --interactive/-i flag, once per album
  • Shares the confirmed albums at --role (default viewer), skipping albums the user already has access to

Example

# Share every album whose name contains "Amy" or "Amelia" with Julia, deciding album-by-album
immich-admin client-workflow add-users-to-album-with-pattern --include "Amy|Amelia" --user Julia --interactive

Full PR

• Add client-workflow to bulk-share albums with a user by name pattern by @dhcgn in #20

Full Changelog: v0.8.0...v0.8.0-beta.22

v0.7.0

v0.7.0

Highlights

New repair-assets mode: takeout-json — clean up Google Takeout JSON sidecars

A known Google Photos Takeout export/import failure stores a photo's *.json metadata sidecar in place of the real picture. The asset is pure JSON with no image data — the header and pixels needed to reconstruct the photo are physically gone, so it is unrecoverable by any tool (verified: ffmpeg reports "No JPEG data found", and the upstream repair-takeout-photos carving tool repairs 0 of them). The only safe action is to remove the junk asset.

# Preview first (nothing is deleted)
immich-admin cw repair-assets --mode takeout-json --check-all-assets --dry-run

# Then remove them (to trash; add --force for permanent deletion)
immich-admin cw repair-assets --mode takeout-json --check-all-assets --yes

Detection is deliberately the strictest in the tool. A file is only ever deleted when its leading bytes parse as a complete JSON object and carry the full Google fingerprint — title + photoTakenTime.timestamp + creationTime.timestamp + googlePhotosOrigin must all be present. A real image never parses as a JSON object at all, so a real photo can never be mistaken for a sidecar. Anything that doesn't match is reported skipped-not-sidecar and left completely untouched.

Verified against 26 real corrupt assets: 25/25 sidecars detected, and the 1 genuine video correctly left untouched.

Consistent with the other destructive commands: --dry-run, --yes, --force (permanent vs. trash), --ids-file, --check-all-assets and --album-id all apply. The mode is opt-in only and is not part of --mode all. --keep-original is rejected (there is nothing to keep).

Repair modes now point you at takeout-json

When marker, tiff-tags or all encounter an asset that is actually a Takeout sidecar rather than a repairable image, they now print a per-asset hint to rerun that asset with --mode takeout-json, instead of just reporting it as unrepairable. Supported image types reuse the bytes already downloaded for repair; other extensions (e.g. a .dng that is really a sidecar) are recognized by streaming only the file's head — no full download.

Removed the thumbhash-wait verification (behavior change)

The replace/repair flow no longer waits for Immich to generate a thumbnail before removing the original. Server-side thumbnail generation is asynchronous and its timing depends on too many factors (queue depth, server load, job scheduling) to bound reliably with a fixed timeout, which risked rolling back genuinely successful repairs. The original is now removed as soon as the repaired upload is checksum-verified and its metadata copied; a failed earlier step still leaves the original untouched and rolls back the new upload. Run find-no-thumbhash afterwards to confirm processing, or use --keep-original.

Full behavior

See the README for the complete client-workflow repair-assets documentation, detection details, and sample use cases.

v0.7.0-beta.20

What's Changed

• Remove thumbhash-wait verification from replace/repair asset flow by @dhcgn in #15
• Add takeout-json repair-assets mode (detect & delete Google Takeout JSON sidecars) by @dhcgn in #16
• Release v0.7.0 by @dhcgn in #17

Full Changelog: v0.6.0...v0.7.0-beta.20