Update claude configs#12
Conversation
📝 WalkthroughWalkthroughThe script switches the remote code installation path from manual Go toolchain setup (installing ChangesDependency Installation Refactoring
Estimated code review effort🎯 2 (Simple) | ⏱️ ~8 minutes Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 inconclusive)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.claude/scripts/install_pkgs.sh:
- Around line 10-11: The script currently runs "mise trust" and "mise install"
which can hang or fail if mise isn't installed or if trust prompts require a
TTY; update the bootstrap to first check for the mise binary (use command -v or
which to fail fast with a clear error), then pre-trust local configs by calling
mise trust for the repo config(s) (e.g., mise trust .mise.toml and/or mise trust
<repo-dir>) in non-interactive mode before running mise install, and ensure the
script exits non-zero if mise is missing or trust/install fail; look for the
literal commands "mise trust" and "mise install" in the script to locate where
to add the checks and pre-trust calls.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: d1272c47-934f-4235-bae2-1abeaf54d865
📒 Files selected for processing (2)
.claude/scripts/install_pkgs.sh.claude/scripts/lint_fix.sh
| mise trust | ||
| mise install |
There was a problem hiding this comment.
❓ Verification inconclusive
Script executed:
#!/usr/bin/env bash
set -euo pipefail
# Verify whether mise exists and whether trust supports non-interactive flags.
if ! command -v mise >/dev/null 2>&1; then
echo "mise_not_found"
exit 0
fi
mise --version
mise trust --help | sed -n '1,160p'Repository: khirotaka/omakase
Repository: khirotaka/omakase
Exit code: 0
stdout:
mise_not_found
Script executed:
cat -n .claude/scripts/install_pkgs.shRepository: khirotaka/omakase
Repository: khirotaka/omakase
Exit code: 0
stdout:
1 #!/usr/bin/env bash
2 set -euo pipefail
3
4 if [ "${CLAUDE_CODE_REMOTE:-}" != "true" ]; then
5 exit 0
6 fi
7
8 cd "$CLAUDE_PROJECT_DIR"
9
10 mise trust
11 mise install
12 exit 0
mise trust command non-interactive flags documentation
For mise (mise-en-place), the “trust” subcommand documents these flags (there is no documented interactive prompt flag specific to mise trust; non-interactive behavior is handled by the global --yes / MISE_YES=1 setting for trust prompts): 1) mise trust flags (from the official docs) - -a, --all: Trust all config files in the current directory and its parents. [1] - --ignore: Do not trust this config and ignore it in the future. [1] - --show: Show the trusted status of config files from the current directory and its parents; does not trust/untrust anything. [1] - --untrust: No longer trust this config; will prompt in the future. [1] Usage shown in the docs: - mise trust [FLAGS] [CONFIG_FILE] [1] 2) Non-interactive approval of trust prompts (global “yes-to-all”) - A recent change aligns config-trust prompting with the documented --yes / MISE_YES=1 “answer yes to all confirmation prompts” behavior: when the global yes setting is enabled, config trust validation auto-accepts the “config files are not trusted” prompt, avoiding interactive blocking. [2] Practical implication for non-interactive scripts: - Use MISE_YES=1 or --yes so any “untrusted config” prompt is automatically accepted, instead of waiting for user input. [2] - For explicitly avoiding trust entirely, use mise trust --ignore <config> (or --show/--untrust as needed). [1]
Citations:
- 1: https://mise.jdx.dev/cli/trust.html
- 2: fix(config): respect --yes flag for config trust prompts jdx/mise#8288
mise CLI trust command behavior headless environments
In mise, the “trust” model is specifically about whether mise will parse certain config features (env vars, templates, and path: plugin versions) from config files that are considered trusted. The trust prompt can become an issue in headless/non-interactive environments because it may require user confirmation unless you pre-seed trust in a supported way. 1) What mise trust actually does (interactive vs non-interactive) - mise trust [CONFIG_FILE] marks a config file as trusted, enabling parsing of potentially dangerous features (environment variables, templates, and path: plugin versions) [1]. - The CLI implementation supports non-interactive “show” and “untrust” modes via flags: - --show reports trusted/untrusted status without changing anything [1]. - --ignore marks a config as not trusted and ignores it in the future [1]. - --untrust removes trust (and “will prompt in the future”) [1]. - -a/--all iterates and trusts multiple config files in the current directory and its parents [1]. - The core implementation selects which config file(s) to trust (including walking through untrusted configs when --all is used) and then calls the trust function for each [2]. 2) Why headless environments can still prompt - If a config file is untrusted, mise emits an error telling you to trust it with mise trust [3]. This is problematic in CI/Docker/headless flows where there is no TTY to answer prompts. - In other words: unless you either (a) run mise trust ... ahead of time, or (b) ensure mise considers the config trusted via its supported trust controls, you can still get blocked when untrusted configs are encountered (e.g., during activation/hook-env). 3) Supported non-interactive approaches (trust seeding) A) Run mise trust explicitly during image/build time (recommended) - A maintainer-recommended Docker/non-interactive approach is to run something like RUN mise trust /app/mise.toml during the container build so the runtime user/state already has the trust recorded [3]. B) Pre-configure trusted directories/paths via MISE_TRUSTED_CONFIG_PATHS - mise supports pre-trusting using MISE_TRUSTED_CONFIG_PATHS (intended to avoid per-config interactive trust prompts). Users report that setting it in the execution environment works for trusting the desired directory scope [3]. - However, there are subtleties: discussions indicate that trying to configure trust via certain local/project settings may not behave as expected; the advice in the discussion is to use explicit mechanisms like the environment variable or explicit mise trust in non-interactive contexts [3]. C) Use --yes / MISE_YES=1 to auto-approve trust prompts (with important caveats) - mise has logic to respect the global “yes to all prompts” setting for config trust validation: when the yes setting is enabled, trust_check() short-circuits and auto-accepts the “config files are not trusted” confirmation prompt [4]. - There is evidence that this is intended to avoid interactive blocking when --yes/MISE_YES=1 is used [4]. - But in practice, there are caveats in how/when “yes” is applied. For example, an issue/discussion reports that MISE_YES=1 and even --yes can still prompt for “exec config trust prompts” in some cases (e.g., mise exec) [5]. So you should not rely on --yes universally for headless flows; prefer explicit trust seeding (A/B). 4) Key behavior with shell activation / hook-env in headless environments - mise’s “activation” affects shell PATH / hooks, and there is documented guidance for non-interactive/CI setups: use shims or mise exec rather than relying on prompt-driven PATH updates [6]. - There’s also an “activation inconsistency” discussion describing how untrusted config errors can appear during hook/env phases, and explicitly recommends explicit trust mechanisms for Docker/non-interactive setups (run mise trust ... or set MISE_TRUSTED_CONFIG_PATHS) [3]. Practical recommendation for headless/CI/Docker - Do: run mise trust during the build for the config file(s) you will use [3], or export MISE_TRUSTED_CONFIG_PATHS in the runtime environment so the configs under that directory scope are treated as trusted [3]. - Avoid relying solely on MISE_YES=1 / --yes for trust prompts, because reports indicate it may not cover all “exec config trust prompts” scenarios [5].
Citations:
- 1: https://mise.jdx.dev/cli/trust.html
- 2: https://github.com/jdx/mise/blob/main/src/cli/trust.rs
- 3: mise activation inconsistency jdx/mise#9130
- 4: fix(config): respect --yes flag for config trust prompts jdx/mise#8288
- 5: MISE_YES/--yes does not work for exec config trust prompts jdx/mise#8253
- 6: https://mise.jdx.dev/troubleshooting.html
Harden remote bootstrap against untrusted config and missing dependency.
Lines 10–11 can fail or hang in headless environments if mise is missing or if config files are untrusted (and no TTY is available to respond to trust prompts). Add a dependency check and pre-trust the config file.
The patch below uses mise trust to explicitly mark the config as trusted during bootstrap, which is the documented approach for non-interactive/Docker environments:
💡 Proposed patch
-cd "$CLAUDE_PROJECT_DIR"
+cd "${CLAUDE_PROJECT_DIR:?CLAUDE_PROJECT_DIR is not set}"
-mise trust
+if ! command -v mise >/dev/null 2>&1; then
+ echo "Error: 'mise' is required but not installed." >&2
+ exit 1
+fi
+
+# Pre-trust config to avoid interactive prompts in headless environments
+mise trust ~/.config/mise.toml 2>/dev/null || true
mise install
exit 0If .mise.toml or other local configs exist in the project, include them: mise trust .mise.toml as well.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.claude/scripts/install_pkgs.sh around lines 10 - 11, The script currently
runs "mise trust" and "mise install" which can hang or fail if mise isn't
installed or if trust prompts require a TTY; update the bootstrap to first check
for the mise binary (use command -v or which to fail fast with a clear error),
then pre-trust local configs by calling mise trust for the repo config(s) (e.g.,
mise trust .mise.toml and/or mise trust <repo-dir>) in non-interactive mode
before running mise install, and ensure the script exits non-zero if mise is
missing or trust/install fail; look for the literal commands "mise trust" and
"mise install" in the script to locate where to add the checks and pre-trust
calls.
1 participant
Summary by CodeRabbit