Self-update triggered mid-session leaves kbagent completely uninstalled (worse than #771's stale-version case)

[MichalProchazkaP3]

Summary

kbagent's startup self-update check triggered in the middle of a session
where kbagent was being actively invoked repeatedly (an AI agent running
several kbagent data-app/kbagent storage commands back to back). The
update printed:

Updating kbagent v0.94.0 -> v0.95.0 in the background; it applies once every kbagent process has exited.

...and the next kbagent invocation (a few seconds later) failed outright:

kbagent: command not found

Unlike #771 (where a failed auto-update leaves the old version working),
here the tool disappeared entirely — not just stale, but gone.

Diagnostics performed (nothing found)

• which kbagent / where.exe kbagent (both Git Bash and PowerShell): not found anywhere in PATH.
• uv tool list: no kbagent/keboola-cli/keboola-agent-cli entry at all.
• ls "$(uv tool dir)": no corresponding directory (only an unrelated, unaffected tool is present).
• pip show kbagent / pipx list / python -m kbagent: nothing.
• No ~/.kbagent or similar config/log directory found anywhere under the user profile or AppData.
• No files found under AppData modified in the ~40-minute window around the failure (aside from Claude Code's own session files).

So the self-update appears to have removed the existing uv tool entry as
part of the upgrade attempt, then failed to complete installing the new
one — leaving nothing behind, with no error surfaced and no log to
diagnose from afterward.

Why this matters for agent use specifically

This CLI is explicitly designed to be driven by AI agents (per
for-agents docs). An agent mid-task has no way to notice "an update is
about to happen" ahead of time, no way to defer it, and — per this
report — no way to recover afterward except waiting and hoping, since
there's no local trace to act on. A background self-update firing between
two commands in the same session is a plausible way to hit this on any
long-running agent session, not just an edge case.

Suggested fixes

1. Never trigger the self-update while kbagent is being actively
   invoked in a session (e.g. gate it to only check/apply on the first
   invocation after a period of inactivity, or require an explicit
   kbagent update, not an implicit one during normal command use).
2. Make the update atomic: never remove/unlink the currently-working
   version until the new one is confirmed installed and runnable. Right
   now a failed update can apparently leave zero working versions, which
   is strictly worse than doing nothing.
3. Log the update attempt somewhere durable (even just stdout/stderr
   of the update step itself, or a small log file) so a failure like this
   is diagnosable without needing to forensically search the filesystem.

Environment

• Windows 11, Git Bash (MSYS) + PowerShell
• kbagent v0.94.0 -> v0.95.0 (self-update)
• Installed via uv tool install (inferred; no local trace survived to confirm the exact original install path)
• Used inside an AI agent session (Claude Code) issuing repeated kbagent commands

Related but distinct: #771 (auto-update fails but stale version keeps
working). This report is the case where the update fails AND the working
version is also gone.

[MichalProchazkaP3]

Update: found the actual root cause via pending_update.log

After manually reinstalling (uv tool install git+https://github.com/keboola/cli,
which itself initially failed with the identical error below until I added
UV_LINK_MODE=copy), kbagent printed the log location on its next run:
%LOCALAPPDATA%\keboola-agent-cli\keboola-agent-cli\pending_update.log. That
log shows the real cause, across three consecutive silent background-update
attempts (0.93.1 -> 0.94.0 -> 0.95.0, all same session):

warning: Failed to hardlink files; falling back to full copy. This may lead to degraded performance.
         If the cache and target directories are on different filesystems, hardlinking may not be supported.
         If this is intentional, set `export UV_LINK_MODE=copy` or use `--link-mode=copy` to suppress this warning.
error: Failed to install: cryptography-50.0.1-cp311-abi3-win_amd64.whl (cryptography==50.0.1)
  Caused by: failed to hardlink file from C:\Users\<user>\.uv-tools\keboola-cli\Lib\site-packages\cryptography\py.typed to C:\Users\<user>\AppData\Local\uv\cache\archive-v0\...\cryptography\py.typed: The cloud operation cannot be performed on a file with incompatible hardlinks. (os error 396)

os error 396 is Windows' ERROR_CLOUD_FILE_INCOMPATIBLE_HARDLINKS —
this fires when the uv cache and/or ~/.uv-tools sit on a
cloud-sync-managed volume (OneDrive Files-On-Demand, or similar) that
doesn't support hardlinking across the two paths involved. uv itself
already detects this and tells you the fix in its own warning line —
but that's exactly the line the self-updater's wrapper swallows.

Manually running the exact recovery command kbagent printed
(uv tool install --force --reinstall "keboola-cli @ https://...whl")
reproduces the same failure verbatim. Prefixing it with UV_LINK_MODE=copy
succeeds immediately and restores a working kbagent.

This confirms and sharpens suggested fix #2 from the original report:
the self-updater's internal uv tool install invocation should either
pass --link-mode=copy itself, or at minimum detect this specific uv
warning/error and retry with it automatically before giving up — since
uv already knows the fix and says so on its own stderr, one line above
where the install then fails.

Also worth flagging: the failure happened identically and silently on
three separate background-update attempts in the same session
(0.93.1, 0.94.0, 0.95.0), each presumably re-triggered by the next
kbagent invocation — reinforcing suggested fix #1 (don't keep retrying
a background update that already failed once per process lifetime,
inside a single active session).