mosaicstack/stack
1
0
Fork 1
Code Issues 207 Pull Requests 14 Actions Packages Projects Releases 15 Wiki Activity

producer: something writes root:root into bind-mounted agent worktrees (apps/gateway/dist x3), blocking pre-push hooks #1097

New Issue
Open
opened 2026-08-07 06:53:40 +00:00 by Mos · 0 comments
Mos commented 2026-08-07 06:53:40 +00:00
Contributor
Copy Link
Copy Source

Something writes root:root into bind-mounted agent working trees, and it blocks pushes

Three occurrences across a week, in three different clones under ~/agent-work:

be-coder-06/stack-1043/apps/gateway/dist          root:root   2026-08-06 00:19
rm-01-ac8-work2-df7530ae/apps/gateway/dist        root:root   2026-07-31 19:22
rm-01-ci-proof-0f706119/apps/gateway/dist         root:root   2026-07-31 18:29

All are apps/gateway/dist — .gitignored generated output (.gitignore:3: dist), ~1.1 M, one file each.

Why it matters

It stops delivery. be-coder-06 could not push #1073: the mandatory pre-push hook runs a gateway typecheck, which fails EACCES writing apps/gateway/dist/apps/gateway/tsconfig.typecheck.tsbuildinfo. It correctly refused to bypass the hook, attempted an unprivileged move, and stopped at the privilege boundary — leaving an approved PR stuck on a file-ownership problem.

The seat that hits this has no way to fix it: the tree is root-owned and the agent is not root.

Likely producer — stated as a hypothesis

A container run writing into a bind-mounted working tree without --user $(id -u):$(id -g). Anything invoked as docker run -v $PWD:/w … will write as root by default.

I ran ci-base twice tonight with -u "$(id -u):$(id -g)" explicitly and produced no root-owned files. Something else does not pass it. I have not identified which caller, and I am not guessing at one.

What I did and did not do

  • Did: sudo chown -R hermes:hermes on the single tree blocking #1073, after confirming it is .gitignored generated output. Verified writable afterwards. Nothing deleted.
  • Did not: touch the other two. They block nothing and are not mine to alter.
  • Did not: rm anything, or attempt to identify the producer by running candidate commands.

chown was chosen over the move be-coder-06 proposed because it is reversible and leaves the decision about that generated tree with the seat that owns the clone.

What would actually fix it

Find the caller that runs a container over a bind-mounted worktree without --user, and pass it. Cleaning up trees is treating the symptom — this is the third in a week and the next one will block someone else's push at an equally inconvenient moment.

Note for whoever picks it up

Agents on this host do not appear to have sudo; mos-claude does. So a seat hitting this cannot self-serve, and will correctly stop — as be-coder-06 did. Until the producer is fixed, this class of block needs an operator or mos-claude every time.

## Something writes `root:root` into bind-mounted agent working trees, and it blocks pushes Three occurrences across a week, in three different clones under `~/agent-work`: ``` be-coder-06/stack-1043/apps/gateway/dist root:root 2026-08-06 00:19 rm-01-ac8-work2-df7530ae/apps/gateway/dist root:root 2026-07-31 19:22 rm-01-ci-proof-0f706119/apps/gateway/dist root:root 2026-07-31 18:29 ``` All are `apps/gateway/dist` — `.gitignore`d generated output (`.gitignore:3: dist`), ~1.1 M, one file each. ## Why it matters It **stops delivery**. `be-coder-06` could not push #1073: the mandatory pre-push hook runs a gateway typecheck, which fails `EACCES` writing `apps/gateway/dist/apps/gateway/tsconfig.typecheck.tsbuildinfo`. It correctly refused to bypass the hook, attempted an unprivileged move, and stopped at the privilege boundary — leaving an approved PR stuck on a file-ownership problem. The seat that hits this has no way to fix it: the tree is root-owned and the agent is not root. ## Likely producer — stated as a hypothesis A container run writing into a bind-mounted working tree **without** `--user $(id -u):$(id -g)`. Anything invoked as `docker run -v $PWD:/w …` will write as root by default. I ran `ci-base` twice tonight with `-u "$(id -u):$(id -g)"` explicitly and produced no root-owned files. **Something else does not pass it.** I have not identified which caller, and I am not guessing at one. ## What I did and did not do - **Did:** `sudo chown -R hermes:hermes` on the single tree blocking #1073, after confirming it is `.gitignore`d generated output. Verified writable afterwards. **Nothing deleted.** - **Did not:** touch the other two. They block nothing and are not mine to alter. - **Did not:** `rm` anything, or attempt to identify the producer by running candidate commands. `chown` was chosen over the move `be-coder-06` proposed because it is reversible and leaves the decision about that generated tree with the seat that owns the clone. ## What would actually fix it Find the caller that runs a container over a bind-mounted worktree without `--user`, and pass it. Cleaning up trees is treating the symptom — this is the third in a week and the next one will block someone else's push at an equally inconvenient moment. ## Note for whoever picks it up Agents on this host do not appear to have sudo; `mos-claude` does. So a seat hitting this **cannot** self-serve, and will correctly stop — as `be-coder-06` did. Until the producer is fixed, this class of block needs an operator or `mos-claude` every time.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
Defect in framework tooling or delivered code
 fleet-enhancement
Fleet-wide reliability/speed/cost improvements surfaced by the nightly enhance pass
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
be-coder-05 be-coder-06 be-coder-07 be-coder-08 coder-mos1 coder-mos2 f10-coder jason.woltje (Jason Woltje) merge-gate mos-dt-0 pepper rev-974 (Rev-974 (Mosaic reviewer seat, web1)) rev-security-02 scooby (Scooby) velma
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: mosaicstack/stack#1097