fix(cli): claude auth fix for CLAUDE_CONFIG_DIR set and not set

[ctrlok]

Hey! After #691 I found that I still have an issue with login to claude for both cases (with and without CLAUDE_CONFIG_DIR).
The issue was that while claude had access to read keychain entries "Claude Code-credentials-hash" - it had no ability write them because of

security: SecKeychainItemModifyContent: UNIX[Operation not permitted]
security: SecKeychainItemCreateFromContent (<default>): UNIX[Operation not permitted]

NONO DIAGNOSTIC
────────────────────────
Command killed by signal 33 (exit code 161).

Sandbox denied the following operations:
  file-write-create  /Users/sevapoliakov/Library/Keychains/login.keychain-db.sb-e6e70b45-VstUEv
  file-write-create  /Users/sevapoliakov/Library/Keychains/login.keychain-db.sb-e6e70b45-nAXm56

And then I tried more ideas based on our research at #684 and #691 and found that claude uses ~/.claude/.credentials or ~/.$CLAUDE_CONFIG_DIR/.credentials if it can't access keychain. It just stores the credentials there.

so I think that by disabling access to keychain for claude we can fix the issue and as well make it more secure. Because there shouldn't be a need to access keychain at all.

As alternative solution, we can access keychain from nono before we starting a sandbox and then pass the credentials to ~/.claude/.credentials file but main problem that it will not allow to refresh token or login to claude from nono sandbox (or we will need to watch the file and do some clever write-back to keychain, which looks hard enough)

Anyway, with current code changes I preserved a symlinks, added support for CLAUDE_CONFIG_DIR and fixed the issue with refreshing a token.

[gemini-code-assist]

Code Review

This pull request updates the sandbox preparation logic to support custom Claude configuration directories via the CLAUDE_CONFIG_DIR environment variable and adds support for Claude's locking mechanism by pre-creating a .lock directory. The review identifies several issues: the custom configuration and lock directories are not currently added to the sandbox capabilities, which will lead to permission denials; the symlink logic does not account for changes to the environment variable once a link exists; and the use of std::fs::rename may fail if the target directory is on a different filesystem.

[ctrlok]

I'm using this build for a two days now and got token refreshed both for my main and work claude accounts.
previously I got issue with claude didn't have ability to write tmp files to update keychain with new token.

[lukehinds]

This is what I have discovered as well, but I am not sure forcing the client to use file based key storage is right. I would rather give slightly more liberal access to the keychain

[ctrlok]

I think there should be both ways possible. At least for me - I'm using Nono to restrict agents to access files and data on my machine, especially passwords by some inaccurate prompt.

I'll update this PR with option of wider keychain access then.

[ctrlok]

@lukehinds wdyt about how better split that - by group or to create a separate profile for credentials on fs and not in keychain?

[ctrlok]

@lukehinds I updated logic that relies on claude-code profile name to rely on included groups and added two groups

claude_code_general_macos - just for check if we running claude-code on macos - it is responsible for all this profile linking and creating a lock directory

claude_code_keychain_macos - responsible for keychain access

I tried to make keychain works, but after few hours of trying I gave up, hope someone else will be able to make it work.

Right now everyone with claude-code profile will have exatly the same experience as before, but it will be possible to use claude_code_general_macos group or exclude claude_code_keychain_macos group to use claude-code with local-file credentials.

The PR may broke expirience for users that use claude_code_macos group in other profiles. Still I think it is fair to show users explicitly that they allow keychain access to claude-code. wdyt?

[lukehinds]

@ctrlok this resolves the general use issue: #722

I figure we then layer on top config dir needs. there is also a profile without any keychain access, if you want to always fallback to file.

[ctrlok]

@lukehinds I updated the PR:

removed everything related to groups and leaved support for CLAUDE_CONFIG_DIR and also made everything work with claude-no-kc profile introduced in #722.

[nf-matt]

@ctrlok I added some comments to #733 related to CLAUDE_CONFIG_DIR that may be relevant here. I'm not needing anything special other than exporting that variable and adding --allow for 2 directories.

[lukehinds]

@ctrlok / @nf-matt sorry for the radio silence, I will absolutely circle back to this, just wanted to let the main fix soak for a little while, not had any complaints yet.