#13556 Native provider drops systemd CREDENTIALS_DIRECTORY from agent runs

Version

Paperclip 2026.916.0, local native Codex/ACP execution.

Reproduction

Start Paperclip as a systemd service with LoadCredential= or LoadCredentialEncrypted=.
Confirm the Paperclip service process has CREDENTIALS_DIRECTORY and the service user can read the named credential.
Start a native agent run and inspect presence only: test -n "${CREDENTIALS_DIRECTORY:-}".

The service process has the variable, but the provider process and agent descendants do not. Other systemd execution metadata is removed at the same boundary. A consumer that correctly follows systemd credentials therefore cannot discover the already-readable credential.

Cause

buildNativeProviderEnvironment builds provider env from NATIVE_PROVIDER_HOST_ENV_KEYS. The allowlist includes PATH, HOME, USER, CODEX_HOME, and XDG variables, but not CREDENTIALS_DIRECTORY. Its tests correctly prove arbitrary host secrets do not leak, but do not cover systemd credential delegation. This makes the omission look incidental rather than an intentional denial of systemd credentials.

Expected behavior

Pass CREDENTIALS_DIRECTORY through the native provider host allowlist (with a regression test) while retaining the deny-by-default environment boundary. Do not make consumers hardcode /run/credentials/<unit>: that couples them to a deployment name and reaches around the environment contract.

The directory pointer itself is not a secret; systemd still controls file placement and permissions. In the observed case the agent already runs as the service user and can read the credential path, so exposing the pointer does not widen filesystem authority.