Development record
The implement loop's worktree store check (ensureStore in internal/core/implement/loop/lane.go) refuses every group-writable level, which is stricter than the product thinker's 2026-10-11 ruling for abcd's own home (admit a group-writable directory when the owner is the group's sole member, fixed for the home by iss-2609290703091174). Found by lane C on 2026-10-12.
issueopenminoriss-2610120640454742
The implement loop's worktree store check (ensureStore in internal/core/implement/loop/lane.go) refuses every group-writable level, which is stricter than the product thinker's 2026-10-11 ruling for abcd's own home (admit a group-writable directory when the owner is the group's sole member, fixed for the home by iss-2609290703091174). Found by lane C on 2026-10-12.
Frontmatter
| id | iss-2610120640454742 |
|---|---|
| type | issue |
| lifecycle | open |
| severity | minor |
.abcd/work/issues/open/iss-2610120640454742-ensurestore-stricter-than-group-ruling.md
open on GitHub ↗ · commit history ↗
mentions1
- iss-2609290703091174Open question for the product thinker: should abcd refuse to read its own settings from a ~/.abcd folder that the owner's group can write to? Today it refuses a folder every account can write, and one another account owns, but reads from a group-writable one (0775). Refusing would protect a machine where the group really is shared with other people. It would also newly refuse ordinary installs on Debian and Ubuntu, where the login umask for a user whose group is private to them is 002, so the documented 'mkdir -p ~/.abcd' makes a 0775 folder whose group is only its owner. abcd's own writers create ~/.abcd at 0755 or 0700, so only a folder made by hand is affected. Two readings already disagree: the declaration file itself is refused when group-writable, and the worktree store (implement/loop ensureStore) refuses a group-writable ~/.abcd level. Deferred out of iss-2609290656480443's fix until ruled.