Repository navigation
Bootstrap: the last two steps run as the user who owns the install #412
Description
Activity
- added a parent issue
on Oct 7, 2026 I'd like to take this one. Findings from a first read of
scripts/atlas-bootstrap.shondev:run_doctorrunspython3 -m atlas.commands.doctorin a plain$(cd "$install_dir" && python3 …)subshell — as root undersudo bash.build_asa_steering_vectorcheckscommand -v atlasand runsATLAS_CONTROL_VECTOR=… atlas asa checkdirectly — root's PATH will not see the user's~/.local/bin/atlas, so an existing good vector fails the check and gets rebuilt. That is exactly the symptom in the issue.
Plan:
run_doctor: go throughrun_as_target sh -c "cd …"(same shape as the TUI build steps).- the vector check:
run_as_target env ATLAS_CONTROL_VECTOR=… atlas asa check, and make thecommand -v atlasprobe see the target user's PATH too. - a test in
tests/infrastructure/that reads the script: every step that runs code from the checkout (python3 -m atlas…,$asa_dirscripts,pip install -e,go build,./scripts/*.sh) goes throughrun_as_target. - the sudo CI job already asserts
stat -c %U /work— I'll add afind /work ! -user atlas-userempty check so a root-owned file at any depth fails the job.
/claim
(the findings and the plan are in my comment above)@assassinationss only issues marked Ready can be claimed, and its status is Backlog. Ready issues are in Start Here.
@assassinationss thank you for the read and the plan. Two things stand in the way for now, and neither is about your work:
- You hold two issues (Japanese docs: resync README and ARCHITECTURE with the English versions #204 and Korean docs: resync README and ARCHITECTURE with the English versions #205), and two is the limit for open claims.
- This issue is not marked Ready. Other work on
scripts/atlas-bootstrap.shis open, and this one waits for a maintainer's look at how the two fit together.
Your findings stay here and will be used. When #204 is closed and this issue is Ready, it is free to claim.
What needs doing
run_doctorand the check of an existing steering vector inbuild_asa_steering_vectorrun as the user the script runs as. Withsudo bashthat is root. Run both throughrun_as_target, as theclone, the CLI install, the model download and the TUI build are.
Why
Root then runs code from a folder that the user owns, and can leave
files there that the user cannot change. After
sudo bashtheatlascommand may also not be on root's path; then the vector checkcannot pass and the vector is built again.
Done when
checkout goes through
run_as_target.no file in the checkout that the user does not own.