Unclear What makes a process count as pinned to the stored login, or as a tool-server daemon, is not stated.
What
Several settings each hold a command that Claude Code runs to fetch credentials or headers: apiKeyHelper, awsAuthRefresh, awsCredentialExport, gcpAuthRefresh and otelHeadersHelper. Before this release, Claude Code read the setting and used it directly. Now each of these settings goes through a guard first:
- A process pinned to the stored login ignores the helper command and uses the answer from a hook instead. A hook is a user-defined command that Claude Code runs at a set point.
- A tool server's background process, called a daemon, does not run any helper. The setting stays in place but its command is not run.
- In both cases Claude Code logs a warning.
Separately, Claude Code has a check for whether a helper command came from project or local settings. Before, that check matched only those two places. For otelHeadersHelper, awsAuthRefresh and awsCredentialExport, it now also passes when another, newly added check says so. That other check may cover a managed or held settings source, but this was not confirmed.
Why
If you rely on one of these helpers, its command may now silently not run in a pinned process or a tool-server daemon. Check the log for a warning when credentials do not refresh as expected. The broader trust check may also change when a helper counts as coming from your project and needs your approval.
What makes a process count as pinned to the stored login, or as a tool-server daemon, is not stated.