CLI on Mac creates config on root user

[stalderPascal]

What happened?

When using pinniped for the first time to login to a cluster, the config files under ~/.config/pinniped get created.
If you do that first login with sudo. these files have owner root and no permissions for anyone else.

that leads to logins done with any other user not being able to read or change the config, and doing a complete login via browser every time auth is required. (potentially other issues that arise without config available)

this behavior also happens without any hint that config could not be read.

Log in by visiting this link: https://example.domain/oauth2/authorize?access_type=offline&client_id=pinniped-cli&code_challenge=...&code_challenge_method=S256&nonce=f45b19e2a9fe7fdf6084a82ea9ffbbd7&pinniped_idp_name=idp&pinniped_idp_type=oidc&redirect_uri=https%3A%2F%2Fsummer-heart-0930.chufeiyun1688.workers.dev%3A443%2Fhttp%2F127.0.0.1%3A49395%2Fcallback&response_mode=form_post&response_type=code&scope=groups+offline_access+openid+pinniped%3Arequest-audience+username&state=...

What did you expect to happen?

executing pinniped commands with sudo should not break the setup. Or at least warn me that there is an issue.

What is the simplest way to reproduce this behavior?

• Have working setup with valid kubeConfig
• delete ~/.config/pinniped/ folder rm -rf ~/.config/pinniped
• run any kubectl command using sudo e.g.sudo kubectl get pods -A
• check: sudo ls -la ~/.config/pinniped

In what environment did you see this bug?

• Pinniped client version: v0.44.0
• OS (e.g: cat /etc/os-release): macOS Tahoe 26.2
• Kernel (e.g. uname -a): Darwin EMP16-CPQ6-pass 25.2.0 Darwin Kernel Version 25.2.0: Tue Nov 18 21:09:45 PST 2025; root:xnu-12377.61.12~1/RELEASE_ARM64_T6030 arm64

---

edit:

** Workaround / Fix **

• sudo rm -rf ~/.config/pinniped/
• kubectl get pods -A (without sudo)

[cfryanr]

Thanks for creating this issue @stalderPascal.

I was able to reproduce the behavior that you saw. I think it is expected that using sudo to run the pinniped CLI will cause those files to be owned by root and not viewable/editable by any other user. I would recommend avoiding the use of sudo with the Pinniped CLI, since sudo should never be required for the pinniped CLI.

I also reproduced the behavior that you saw where the pinniped CLI does not output any error or warning that these cache files are not readable or writable. It will quietly fail to read or write the cache, resulting in the same behavior as if you deleted the cache between every command. More specifically, it will always assume that you need to perform a fresh login. This is not ideal. It should at least print some kind of error or warning so you know that the cache directory is not working. This should be improved.