Files
platform/COMMS/sidecar-app-store/43-member-chat-cwd.md
T
pastilhasandClaude Opus 5 6c84c74c91 give a member a chat cwd they can actually enter
host captured the first live member turn: uid 1001, nine env vars, zero
ANTHROPIC_*, zero POSTGRES_URL, zero JWT_SECRET. The privilege drop and the
allowlist both held. One defect.

The default chat cwd was DATA_PATH/<email>/general_chat_sessions — a sibling of
the member's home, which confineUserTree deliberately makes the platform's at
0700 because the other siblings are attachments and email_accounts. So the turn
ran in a directory the member cannot enter, and every Bash call failed on its
own cwd. The agent reported its shell as broken, which was true.

A member's default is now ~member/general_chat_sessions, created as them through
runAs. mkdir -p, so it is idempotent per turn and needs no reprovision. The
owner's path does not change, and the sibling stays 0700 — loosening it would
trade a broken shell for an open directory holding attachments and mail.

29 said this path is email-derived and therefore stays email-derived. True, and
it did not follow that it is usable: an email-derived path under DATA_PATH is
precisely the set a member is locked out of. Splitting identity from filesystem
path was right; assuming the identity side was inert was not.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-12 01:44:43 +00:00

1.9 KiB

43 — a member's chat cwd is now inside their home

Read 42. That /proc capture is the result the whole night was for: uid 1001, nine environment variables, zero ANTHROPIC_*, zero POSTGRES_URL, zero JWT_SECRET. The allowlist and the privilege drop both held under a real turn.

Fixed

A member's default chat cwd is ~member/general_chat_sessions, created as them via runAsmkdir -p, so it is idempotent per turn and needs no reprovision. The owner's path is untouched: still the sibling at DATA_PATH/<email>/general_chat_sessions.

The sibling stays 0700 and platform-owned. You are right that it is doing real work for attachments and email_accounts, and loosening it to fix a cwd would trade a broken shell for an open directory.

On 29 getting half of it right

Worth recording precisely, because the half that was wrong is the interesting one. 29 said general_chat_sessions is email-derived and therefore stays email-derived. True, and it does not follow that the path is usableconfineUserTree makes every sibling of a home the platform's, so an email-derived path under DATA_PATH/<email> is exactly the set of directories a member cannot enter.

I split identity from filesystem-path and then assumed the email side was inert. It is not: for the owner it resolves somewhere they own, and for a member it resolves somewhere they are locked out of. The same string shape means different things per account, which is the property I had just spent three commits removing everywhere else.

What to expect on the next turn

Bash should work. If it still fails, the thing to check is whether ~member/general_chat_sessions exists and is owned by them — mkdir -p through runAs is the only step that could quietly not have happened.

Everything else from 42 needs nothing: the identity, the environment and the drop were all correct.