Self-update silently aborts (never applies) when git stash prints a warning, e.g. ".a0_env: Device or resource busy"

[Sergio-72]

Description

self_update_manager.py's update flow (triggered via trigger_self_update.sh / the "Restart and Update" button in the Self Update UI dialog) never actually applies the update, even though the UI shows "Update available" and the process appears to run and restart successfully. The instance stays pinned to the old commit indefinitely.

Root cause

In the docker deployment, /a0 is a git checkout and .a0_env (the venv directory) lives inside it. During the update flow, the code runs:

git -C /a0 stash push --include-untracked --message "a0-self-update rollback snapshot ..."

This command actually succeeds (stdout: Saved working directory and index state On main: ...), but git also writes a benign warning to stderr because the venv currently in use can't be removed while it's running:

warning: failed to remove .a0_env: Device or resource busy

The update flow treats this non-empty stderr as a hard failure and aborts with:

Update flow failed: Failed to save local tracked/untracked changes before updating.

...before ever reaching the actual git fetch/checkout to the new version. The container then just relaunches the UI on the old commit. Since there's no error surfaced to the browser (the "Update in progress" dialog just resolves back to "healthy"), this is silent from the user's perspective — it looks like the update succeeded but the version never changes.

Confirmed via /exe/a0-self-update.log:

[...] $ git -C /a0 stash push --include-untracked --message a0-self-update rollback snapshot ...
[...] stdout:
    Saved working directory and index state On main: a0-self-update rollback snapshot ...
[...] stderr:
    warning: failed to remove .a0_env: Device or resource busy
[...] Update flow failed: Failed to save local tracked/untracked changes before updating.

We also found three separate stash entries accumulated from repeated automatic retry attempts over a few hours, each failing the same way — so this isn't a one-off, it reproduces consistently whenever the venv dir is present/in-use inside the repo at update time.

Steps to reproduce

1. Run Agent Zero in Docker with the standard layout (.a0_env venv living under /a0).
2. Have any local modification present under /a0 (agent-generated prompt/skill edits count, since it self-modifies prompts//skills/ during normal use).
3. Trigger a self-update (branch main, tag latest or an explicit newer tag) via the UI or trigger_self_update.sh.
4. Observe: UI shows "Update in progress" → "healthy" again, but git -C /a0 log -1 still shows the old commit; /exe/a0-self-update.log shows the stash-warning abort above.

Expected behavior

A git stash that succeeds (per stdout / exit code) should not be treated as a failure just because it printed an unrelated warning to stderr about a busy file it couldn't remove. The update flow should check the actual exit code, or at minimum log/surface the distinction between "stash failed to save changes" (real failure) and "stash saved changes but had an unrelated non-fatal warning."

Workaround

Manually run, then restart the container:

git -C /a0 fetch origin --tags
git -C /a0 checkout --force v2.5   # or whichever target tag

Environment

• Deployment: Docker (agent0ai/agent-zero image), instance was on v2.1 (commit 48087de), target was v2.5.