Linux Codex task HOME isolation prevents reuse of host CLI credentials outside seeded paths

[xfap]

Summary

On Linux, Multica Codex tasks run with a task-local HOME when using the workspace-write sandbox. This protects the host home directory, but it also means host-authenticated CLI credentials are unavailable unless Multica explicitly seeds their paths into the task home.

This creates a platform difference: macOS Codex tasks keep the host HOME, while Linux Codex tasks use an isolated task HOME.

Observed behavior

A CLI can be authenticated and work in a normal Linux terminal, but fail inside a Linux Multica Codex task because its credential cache is not present in the task-local home directory.

This affects any external CLI whose credentials are outside the current built-in seed list. Examples:

• Docker CLI auth: ~/.docker/config.json
• AWS SSO/cache credentials: ~/.aws/sso/cache
• Google Cloud CLI auth: ~/.config/gcloud
• Other vendor CLIs that store OAuth/session state under their own dot directories or XDG config/data paths

GitHub CLI is not a representative example here because Multica already appears to seed GitHub-related config. The broader issue is credentials for tools that are not in the fixed allowlist.

Expected behavior

Linux Codex tasks should have a safe, explicit way to reuse selected host-authenticated CLI credentials without exposing the entire host HOME.

Actual behavior

Linux Codex tasks only receive a fixed set of seeded files/directories. Credentials outside that set are unavailable, so CLIs may prompt for login again, time out waiting for OAuth, or fail in non-interactive agent tasks.

macOS does not show the same behavior because the task keeps the host HOME.

Why not mount the full host HOME

Mounting the full host home would expose unrelated local state and secrets, such as SSH keys, cloud credentials, browser/session files, Git credentials, and private application data.

A narrower opt-in mechanism seems safer.

Possible direction: task-home auth snapshots

Would a configurable task-home auth snapshot mechanism be acceptable?

The rough design:

• Add an opt-in config such as task_home_snapshot_paths.
• Each path is relative to the daemon user's real home.
• On Linux Codex workspace-write tasks, the daemon copies those paths into the task-local HOME.
• The task can read and update its local copy, but changes are not written back to the host.
• Missing paths warn and skip.
• Unsafe paths fail task preparation.

Security constraints:

• Require normalized relative paths.
• Reject absolute paths and ...
• Do not follow symlinks.
• Copy only regular files and directories.
• Use restrictive permissions, for example 0700 for directories and 0600 for files.
• Keep this disabled by default.

This would preserve the Linux sandbox boundary while allowing users to opt in only the credential caches needed for specific external CLIs.

Questions

Is this direction aligned with Multica's intended Linux sandbox model?

Should this configuration live in daemon/profile config, runtime config, or agent-level config?

Would copying selected credential paths into task-local HOME be preferred over symlinking or bind-mounting them?

Environment

• Deployment type: self-host
• Multica CLI: 0.4.4
• Codex CLI: 0.144.5
• Platform difference observed between Linux and macOS Codex task environments