Changed

• The new-version hint now also follows a failed command, --version, and a rejected argument - It previously appeared only after a successful run, which is when it matters least. The motivating case is the opposite one: a user on a build predating the flag they are passing sees unexpected argument, concludes the feature is broken, and has nothing pointing at their own install. That is not hypothetical — it is the --recursive report described in the note below, which cost a support round trip and a release spent chasing a defect that user never hit. Argument parsing no longer lets clap exit on pcli2's behalf, so a usage error or a --version check can still be told the binary is out of date, and a failed command prints the hint after the error so it is the last thing read. --help is excluded: its output is long enough that a trailing line would scroll past unread. Every existing restraint still applies — terminal sessions only, at most one check per 24 hours, never in CI, and PCLI2_NO_UPDATE_CHECK still disables it entirely.

Notes

• Correction to the v1.18.3 entry below. That fix was attributed to a field report of --recursive "not working". The report turned out to have a different cause — an old pcli2 earlier on the user's PATH, in a shell where --recursive did not yet exist — so the silent-fallback defect it describes was not what that user hit. The defect is real and the fix stands: a recursive scan really could degrade to listing only a folder's direct children, with the explanatory warning painted over by the --progress spinner. But it was found by reasoning backwards from the symptom rather than by reproducing it, and there is no evidence it has ever triggered in the field. Worth knowing before treating a low recursive count as that bug: check pcli2 --version in the shell actually being used first.