On macOS, XPC_SERVICE_NAME variable being set to 0

[MageJohn]

Describe the bug

Whenever direnv sets the environment on my Mac, it sets a variable called XPC_SERVICE_NAME to 0. This appears to be a variable set by macOS, and without direnv it's set to a value related to the terminal the shell is running in.

To be clear, XPC_SERVICE_NAME is not being explicitly set in my .envrc or .env file. I have tested this with both.

To Reproduce

Steps to reproduce the behavior:

1. Set up direnv for your shell on macOS Ventura 13.4 (untested on other versions)
2. In an empty directory (no .envrc file), do echo $XPC_SERVICE_NAME. You should see something like application.com.foo.bar.12345678.12345678, corresponding to your terminal app.
3. Run touch .envrc.
   • You should now have an empty .envrc.
   • direnv should inform you that the file is blocked.
4. Run direnv allow
   • You should see direnv load your file
   • You should also see it export XPC_SERVICE_NAME.
5. Confirm that echo $XPC_SERVICE_NAME outputs 0.

Expected behavior

No environment variables should be set, as none were defined in the .envrc file.

Environment

• OS: macos Ventura 13.4
• Shell: fish (also tested in bash)
• Direnv version: 2.32.3

Additional context

I would guess that this has something to do with spawning the subshell; however, just starting bash doesn't seem to cause the XPC_SERVICE_NAME variable to change.

Note that though the steps to reproduce use an empty .envrc, this also occurs when variables are set in it.

In terms of prioritisation, this is not currently causing any issues for me, just noise in direnv's output when changing directories. That could change – I don't know what programs might rely on the value of XPC_SERVICE_NAME.

[Samuel-Martineau]

This also affects macOS 14.0

[sandinmyjoints]

Seeing it on 14.2.

[vicmunoz]

Affects 14.4 too