Symptoms:

Healthcheck fails repeatedly: Healthcheck error: Error: connect ECONNREFUSED <app-ip>:5678 (previously EHOSTUNREACH)
On every start attempt, npm fails while installing extra node modules:
npm error code EACCES
npm error syscall mkdir
npm error path /home/cloudron/.npm/_cacache/tmp
npm error errno EACCES
npm error Your cache folder contains root-owned files...
npm error sudo chown -R 1000:1000 "/home/cloudron/.npm"
This happens even on a freshly recreated container (Cloudron deleted and recreated the container as part of a repair/debug task), so it's not a leftover from the old container's filesystem — it recurs immediately on the new one too.
The package's own start.sh already runs chown -R cloudron:cloudron /app/data /run/n8n /run/.npm /run/.cache /run/*.ssh before the npm install step for PKG_EXTRA_NODE_MODULES (a handful of custom node packages), yet the EACCES persists.
The app also briefly entered a Cloudron "Repair mode... sleeping" state during one restart attempt, which I've since disabled.

What I've checked:

/run/cloudron.npm (symlink target of /home/cloudron/.npm) is present and empty, owned by cloudron:cloudron (uid 1000).
No supervisorctl socket present (/var/run/supervisor.sock doesn't exist) — image apparently doesn't run supervisord for shell access, only via the packaged start.sh → exec supervisord.
/run is mounted as ext4, not tmpfs, so it's not a "wiped on restart" issue.

Question:
Is /run/cloudron.npm (or its _cacache subfolder specifically) expected to sometimes get root-owned entries from an npm install step that runs as root before the gosu cloudron:cloudron npm install line, and if so, is there a known race/ordering bug in the n8n package's start.sh between the chown and the actual npm install for PKG_EXTRA_NODE_MODULES?

Workaround used: Restoring from an earlier backup instead of continuing to debug live, since the app was fully down.

Environment:

Cloudron app: n8n (io.n8n.cloudronapp@4.40.0)
Cloudron CLI used for restart/logs