Re: Critical infrastructure update failing in TLU alone

> On 21 Aug 2026, at 23:07, Adam R. Maxwell <[email protected]> wrote:
> 
>> On Aug 21, 2026, at 11:38 , Bruno Voisin <[email protected]> wrote:
>> 
>> I tried giving full disk access (in System Settings > Privacy & Security) to
>> 
>> /Applications/TeX/TeX Live Utility.app
> 
> TLU is not sandboxed, so it already has full disk access, I think. You're more likely to break things permanently by messing around like this, IMHO.

I just did that for testing, to see whether this had an influence. As soon as I posted my message yesterday, I removed all the full disk accesses I had added.

>> But maybe this isn't related at all. I imagine in a month or so when macOS OS 27 is released we'll see how things are.
> 
> Has Apple responded to the bug report I assume you filed? That's the point of installing their OS betas, after all!

I haven't filed any bug yet (related to this), as I don't know what to file; namely, which specific part of the OS isn't behaving the way it's expected to.

> I finally figured out why the LogEnvironment default wasn't working, though. Give this a try, and you should see what PATH is for the privileged task when you try updating:
> 
> sudo -H defaults write com.googlecode.mactlmgr.tlmgr_cwrapper LogEnvironment -bool TRUE

The output is puzzling.

Here's what TLU puts in the log when it's launched (it has always displayed that, I'm just writing it for comparison)

Current environment from /usr/bin/env:
__CF_USER_TEXT_ENCODING=0x1F5:0x0:0x0
__CFBundleIdentifier=com.googlecode.mactlmgr.tlu
CC_FOR_BUILD=no_compiler_found
COMMAND_MODE=unix2003
DISPLAY=/var/run/com.apple.launchd.hh7MHGtq6L/org.xquartz:0
HOME=/Users/brunovoisin
LOGNAME=brunovoisin
OSLogRateLimit=64
PATH=/Library/TeX/texbin:/usr/local/bin:/System/Cryptexes/App/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin
SHELL=/bin/zsh
SSH_AUTH_SOCK=/var/run/com.apple.launchd.SwYvWRXn5s/Listeners
TMPDIR=/var/folders/jk/khszwygs023gr2sdrkk02w100000gn/T/
USER=brunovoisin
XPC_FLAGS=0x0
XPC_SERVICE_NAME=0

And here's what TLU says (after changing things as above), when the infrastructure update is asked for

tlu_ipctask: Current environment
__AUTHORIZATION=auth 3
__CF_USER_TEXT_ENCODING=0x0:0:1
__CFBundleIdentifier=com.googlecode.mactlmgr.tlu
_BASH_IMPLICIT_DASH_PEE=-p
CC_FOR_BUILD=no_compiler_found
COMMAND_MODE=unix2003
DISPLAY=/var/run/com.apple.launchd.hh7MHGtq6L/org.xquartz:0
HOME=/var/root
LOGNAME=brunovoisin
OSLogRateLimit=64
PATH=/usr/bin:/bin:/usr/sbin:/sbin
SHELL=/bin/zsh
SSH_AUTH_SOCK=/var/run/com.apple.launchd.SwYvWRXn5s/Listeners
USER=brunovoisin
XPC_FLAGS=0x0
XPC_SERVICE_NAME=0

So this would mean that /etc/paths, containing

/usr/local/bin
/System/Cryptexes/App/usr/bin
/usr/bin
/bin
/usr/sbin
/sbin

isn't even taken into account. Which (thanks to Google's IA overview when asking for "/etc/paths") would mean /usr/libexec/path_helper isn't involved when tlu_ipctask runs.

Actually, the exact ordering of things in the log, after update-tlgmr-latest.sh and its sha512 are downloaded and checked yielding an "okay to run tlu_ipctask", is

(1) Invoking privileged task via AuthorizationExecuteWithPrivileges
(2) tlu_ipctask: Current environment [...]
(3) dropped privileges to user nobody 

So this is down to AuthorizationExecuteWithPrivileges being broken in the latest Golden Gate betas?

And where does this _BASH_IMPLICIT_DASH_PEE come from?

> Output from this and Karl's changes should be illuminating (and if Karl's are in tlcritical, you can try both).

Indeed, here's what I got when installing TeX Live Manager from critical repository:

0%    47%    95%  100%   MD5 checksums are OK.     0%    47%    95%  100%  ./runme.sh: line 15: kpsewhich: command not found
./runme.sh: Cannot find TeX Live root using kpsewhich --var-value=SELFAUTOPARENT.
./runme.sh: (no tlpkg/texlive.tlpdb and/or tlpkg/tlpobj/.)
./runme.sh: Please set your PATH as needed, otherwise it's hopeless. Current PATH:
./runme.sh:   /usr/bin:/bin:/usr/sbin:/sbin

Bruno