env ( ) profile.d file written 0600 root:root — forwarded vars never reach the agent user #4

Summary

env ( … ) in a clawk.mod forwards a host env var into the sandbox, but the generated /etc/profile.d/99-clawk-env.sh is written 0600 root:root, so the agent user can't read it. Login shells run as agent and silently skip unreadable /etc/profile.d/*.sh files, so the forwarded variable never actually gets set in the agent's environment.

Net effect: env ( GITHUB_TOKEN ) looks correct but gh (and anything else relying on the forwarded var) never sees it.

Version: v0.2.0

Root cause

EnvFile writes the file 0600 / root:root:

• internal/sandbox/shares.go:628-630 — GuestPath: "/etc/profile.d/99-clawk-env.sh", Mode: 0o600, Owner: "root:root" (comment: // root-owned; secrets).

Contrast the OAuth token file, which is the same class of secret but written 0644 so the agent's login shells can source it:

• internal/sandbox/oauth_token.go:223-224 — GuestPath: "/etc/profile.d/98-clawk-claude-oauth.sh", Mode: 0o644.

And the code already documents the readability requirement:

• internal/sandbox/oauth_token.go:204 — “… /etc/profile.d/*.sh that aren't readable get silently skipped …”

So CLAUDE_CODE_OAUTH_TOKEN (0644) works while GITHUB_TOKEN via env ( ) (0600 root) doesn't.

Reproduce

1. Repo clawk.mod:

   sandbox (
       env ( GITHUB_TOKEN )
   )
   

   with GITHUB_TOKEN exported in the host shell that launches clawk.
2. clawk (create + boot) from that shell.
3. In the guest as agent:

   $ grep GITHUB_TOKEN /etc/profile.d/99-clawk-env.sh
   grep: /etc/profile.d/99-clawk-env.sh: Permission denied
   $ bash -lc 'echo "${GITHUB_TOKEN:+present}"'   # prints nothing
   $ gh auth status                               # not logged in
   

Expected

A variable named in env ( ) is set in the agent's shells (login and interactive) — that's the point of the block.

Suggested fix

Write 99-clawk-env.sh 0o644, matching 98-clawk-claude-oauth.sh. The // root-owned; secrets intent isn't achieved by 0600 here — the agent is the intended consumer, so it must be agent-readable; and it's inconsistent with the OAuth file beside it. If world-readability is a concern, 0o640 with root:<agent-group> would keep it off "other" while staying agent-readable.