fix(sandbox): support claude-code profile extensions and simplify config

[lukehinds]

Issue discovered and reported by @ctrlok

@ctrlok you can use this in yours, or we can merge this, I have added co-author as I don't want to deny you the opportunity to contribute.

• Introduce is_claude_code_profile to correctly identify profiles that are "claude-code" or transitively extend it.
• Update should_auto_enable_claude_launch_services and prepare_sandbox to use this new profile check.
• Replace the symlink-based redirection for ~/.claude.json with setting the CLAUDE_CONFIG_DIR environment variable to ~/.claude.
• This ensures Claude Code writes all its config and temporary files (used for atomic writes during token refresh) into a directory (~/.claude/) that the sandbox already grants read/write permissions to.
• This resolves silently failing token refreshes due to temporary files being created in a non-writable home directory.

[gemini-code-assist]

Code Review

This pull request introduces a recursive check to determine if a profile extends 'claude-code' and simplifies the sandbox preparation logic by replacing symlink-based redirects with the CLAUDE_CONFIG_DIR environment variable. A potential denial-of-service vulnerability was identified in the new is_claude_code_profile function, as it lacks cycle detection for circular profile dependencies, which could lead to a stack overflow.

[ctrlok]

Hey! We can continue with current PR as is. I just think that we also can precreate $CLAUDE_CONFIG_DIR.lock directory, while it is expected to exist for both cases (with and without $CLAUDE_CONFIG_DIR set)

Also, I'll take a look on login issues, while I had problems with login as well and it was caused by two different issues (one of them was access and existance of directory ~/.claude.lock/ if CLAUDE_CONFIG_DIR is not set and ~/$CLAUDE_CONFIG_DIR.lock/ if it was set)

I mean this directory and access to it is directly related to claude-code ability to refresh token and not to ask for login every day.

It can be proved by running claude inside nono with --debug flag.

EPERM: operation not permitted, mkdir '/Users/sevapoliakov/.claude-second-profile.lock'

this lock directory is used only for token refresh as far as I traced.

[lukehinds]

alright - does this look ok @ctrlok ?

[ctrlok]

@lukehinds it looks ok to me, still to fix 'ask for login every day' we need to choose from:

a) precreating folder $CLAUDE_CONFIG_DIR.lock instead of user
b) update documentation to say that this folder should be created by user

[ctrlok]

actually I was wrong, we need to precreate $CLAUDE_CONFIG_DIR - while it removes it right after a token refresh, so next day there will be problem again. Probably it can be fixed in a future nono version with prehook support, but for fix in the current version I'm totally sure that we need to precreate this folder

[lukehinds]

a few more changes needed i just spotted.

[ctrlok]

I think it can be updated to something like this:

        let dir: PathBuf = match std::env::var_os("CLAUDE_CONFIG_DIR") {
            Some(val) => PathBuf::from(val),
            None => {
                let p = home_path.join(".claude");
                #[allow(clippy::disallowed_methods)] // Single-threaded before fork.
                std::env::set_var("CLAUDE_CONFIG_DIR", &p);
                p
            }
        };

        let mut lock = dir.clone().into_os_string();
        lock.push(".lock");
        precreate(Path::new(&lock), true);

I tested it on my local build and it works just fine

then only issue - that we need to be sure that we will not create lock folders for users who do not run claude-related profiles

[lukehinds]

Yes, it's safe. the CLAUDE_CONFIG_DIR set, the lock dir precreation, the cache dir precreation is inside the refactored if args.profile.as_deref().is_some_and(is_claude_code_profile) block. If you're running --profile default, --profile opencode, or no profile at all, none of this executes

I also fixed my mistake, by moving ~/.claude.lock from allow_file to allow in the policy so it's treated as a directory and move precreation of the lock directory before the sandbox kicks in

added some docs as well, just to make sure its there for others.

[lukehinds]

ah crap, I found another issue - going to need to think about this one a little more. when CLAUDE_CONFIG_DIR is explicitly set, Claude Code hashes it into the Keychain service name. So nono's auth detection (runs
before the env var is set) checks claude-code-credentials, finds tokens, thinks auth exists, doesn't enable launch services. But Claude Code sees the env var, looks under claude-code-<hash>-credentials, finds nothing, triggers login with no browser.

[ctrlok]

@lukehinds interesting, I don't have this issue at all, and I'm pretty sure my nono profile don't have access to keychain at all and token with refresh token is stored in the ~/.claude/.credentials.json (or ~/$CLAUDE_CONFIG_DIR/.credentials.json)

Probably different version of claude-code (I'm using from homebrew)

[lukehinds]

Probably different version of claude-code (I'm using from homebrew)

this is one of the issues, they use three different installers (bun, shell and brew).

[lukehinds]

ok, the profile check now walks the inheritance chain so any profile that extends claude-code gets the same setup - symlink redirect, file precreation, and launch services auto-enable.

clear creds and make sure brower open operation is triggerd:

follow up run shows auth still present

custom profile

test with CLAUDE_CONFIG_DIR

Check browser is allowed to open with CLAUDE_CONFIG_DIR

Non-claude profile doesn't touch anything

[lukehinds]

I will get this shipped if sounds good to you @ctrlok

[ctrlok]

@lukehinds hey! Your latest commit break $CLAUDE_CONFIG_DIR support.

I'd love to revert to

       // Set CLAUDE_CONFIG_DIR so Claude Code writes config and lock files
        // inside ~/.claude/ (which the sandbox already grants readwrite).
        // This replaces the old symlink-based redirect for ~/.claude.json
        // and also ensures token refresh temp files land in a writable dir.
        let claude_config_dir = match std::env::var_os("CLAUDE_CONFIG_DIR") {
            Some(dir) => PathBuf::from(dir),
            None => {
                let dir = home_path.join(".claude");
                #[allow(clippy::disallowed_methods)] // Single-threaded before fork.
                std::env::set_var("CLAUDE_CONFIG_DIR", &dir);
                dir
            }
        };

        // Claude Code creates $CLAUDE_CONFIG_DIR.lock/ for token refresh
        // locking, then removes it afterwards. The sandbox blocks mkdir in
        // the parent directory, so pre-create it each time.
        let lock_dir = claude_config_dir.with_extension("lock");
        precreate(&lock_dir, true);

and remove all symlink based logic. Can you please write down what issues you had with the previous approach we did and I'll try to reproduce and fix it.