codeep 3.4.0 → 3.5.0

package/dist/utils/gitHookInstaller.d.ts

@@ -14,7 +14,38 @@ export declare function parseHookArgs(argv: string[]): HookArgs;
 export declare function buildHookScript(hookType: HookType, failOn: FailOn): string;
 /** True when a hook file was created by Codeep (safe to overwrite/remove). */
 export declare function isCodeepHook(content: string): boolean;
-/** Resolve the git hooks directory (honors worktrees + core.hooksPath). Null if not a repo. */
+/**
+ * Where this repository keeps its hooks — as a three-way answer, because two
+ * of the three used to come back as the same `null`.
+ *
+ * `none` means git answered and there is no hook directory to speak of (not a
+ * repository, no git on PATH). `unknown` means git was REFUSED: hardenedGitEnv
+ * would not build an environment for this repository, so nobody can say where
+ * its hooks live or whether a path is one.
+ *
+ * Folding `unknown` into `none` is a fail-OPEN, and it is a live hole rather
+ * than a theoretical one: the write gate in utils/toolExecution.ts reads a
+ * null hook directory as "this repository has no hook directory" and stops
+ * gating, so the one repository whose config Codeep refuses to scan is
+ * exactly the one whose `.githooks/pre-commit` an agent could write
+ * unprompted. A caller that has to decide something must branch on `kind`.
+ */
+export type HooksDirResult = {
+    kind: 'hooks';
+    dir: string;
+} | {
+    kind: 'none';
+} | {
+    kind: 'unknown';
+    reason: string;
+};
+export declare function resolveHooksDirResult(cwd: string): HooksDirResult;
+/**
+ * Resolve the git hooks directory (honors worktrees + core.hooksPath). Null if
+ * not a repo — and THROWS `GitHardeningError` when git was refused, so a
+ * refusal can never be mistaken for "no hooks here". Callers that must not
+ * throw (the write gate) use resolveHooksDirResult() above instead.
+ */
 export declare function resolveHooksDir(cwd: string): string | null;
 export interface HookDeps {
     resolveHooksDir: (cwd: string) => string | null;

package/dist/utils/gitHookInstaller.js

@@ -7,6 +7,7 @@
 import { readFileSync, writeFileSync, mkdirSync, chmodSync, rmSync } from 'fs';
 import { join, dirname, isAbsolute } from 'path';
 import { execSync } from 'child_process';
+import { hardenedGitEnv, GitHardeningError } from './git.js';
 const FAIL_ON_VALUES = ['error', 'warning', 'info', 'none'];
 const MARKER_START = '# >>> codeep hook >>>';
 const MARKER_END = '# <<< codeep hook <<<';
@@ -91,16 +92,71 @@ export function buildHookScript(hookType, failOn) {
 export function isCodeepHook(content) {
     return content.includes(MARKER_START);
 }
-/** Resolve the git hooks directory (honors worktrees + core.hooksPath). Null if not a repo. */
-export function resolveHooksDir(cwd) {
+export function resolveHooksDirResult(cwd) {
+    let env;
     try {
-        execSync('git rev-parse --is-inside-work-tree', { cwd, stdio: 'ignore' });
-        const hooks = execSync('git rev-parse --git-path hooks', { cwd, encoding: 'utf8' }).trim();
-        return isAbsolute(hooks) ? hooks : join(cwd, hooks);
+        // noHooks stays off: answering where the hooks live is this function's
+        // entire job, and an override would have git report the no-hooks path and
+        // send `codeep hook install` there.
+        env = hardenedGitEnv({ cwd });
+    }
+    catch (error) {
+        if (error instanceof GitHardeningError)
+            return { kind: 'unknown', reason: error.message };
+        throw error;
     }
-    catch {
-        return null;
+    try {
+        // stderr is piped rather than ignored so the catch below can tell git's
+        // own answer apart from everything else. Ignoring it is what made the two
+        // indistinguishable in the first place.
+        execSync('git rev-parse --is-inside-work-tree', { cwd, stdio: ['ignore', 'ignore', 'pipe'], env });
+        const hooks = execSync('git rev-parse --git-path hooks', {
+            cwd,
+            encoding: 'utf8',
+            stdio: ['ignore', 'pipe', 'pipe'],
+            env,
+        }).trim();
+        return { kind: 'hooks', dir: isAbsolute(hooks) ? hooks : join(cwd, hooks) };
     }
+    catch (error) {
+        // Only git's own "there is no repository here" is `none`. The bare
+        // `catch { kind: 'none' }` this replaces folded a timeout, an EACCES on
+        // `cwd` and a git that died mid-answer into the same result — and `none`
+        // is what the write gate in utils/toolExecution.ts reads as "this
+        // repository has no hook directory, stop gating", so every one of those
+        // failures turned the gate off. `unknown` keeps it on, which is the only
+        // safe way round to be wrong.
+        const err = error;
+        const stderr = String(err.stderr ?? '');
+        // git's own answer for "there is no repository here". A BARE repository
+        // is deliberately not in this branch: `--is-inside-work-tree` prints
+        // `false` and exits 0 there (verified, git 2.54), so it comes back as a
+        // hooks directory, which is what it has.
+        if (/not a git repository/i.test(stderr))
+            return { kind: 'none' };
+        // git never started: not on PATH, or `cwd` is gone. The caller's own git
+        // calls cannot run either, so there is no hook directory to speak of.
+        if (err.code === 'ENOENT' || err.code === 'EACCES' || err.code === 'ENOTDIR')
+            return { kind: 'none' };
+        const detail = stderr.trim() || err.code || `exit ${err.status ?? '?'}`;
+        return {
+            kind: 'unknown',
+            reason: `Cannot tell where ${cwd} keeps its git hooks: git failed to answer (${detail}). ` +
+                'Codeep treats that as "there may be hooks here" rather than as "there are none".',
+        };
+    }
+}
+/**
+ * Resolve the git hooks directory (honors worktrees + core.hooksPath). Null if
+ * not a repo — and THROWS `GitHardeningError` when git was refused, so a
+ * refusal can never be mistaken for "no hooks here". Callers that must not
+ * throw (the write gate) use resolveHooksDirResult() above instead.
+ */
+export function resolveHooksDir(cwd) {
+    const result = resolveHooksDirResult(cwd);
+    if (result.kind === 'unknown')
+        throw new GitHardeningError(result.reason);
+    return result.kind === 'hooks' ? result.dir : null;
 }
 export function runHookCommand(argv, deps = defaultHookDeps()) {
     const args = parseHookArgs(argv);
@@ -108,7 +164,19 @@ export function runHookCommand(argv, deps = defaultHookDeps()) {
         deps.write(HOOK_HELP);
         return 0;
     }
-    const hooksDir = deps.resolveHooksDir(process.cwd());
+    // `resolveHooksDir` throws rather than answer null when git was refused, so
+    // the two failures get the two different messages they need: "you are not in
+    // a repo" is not a useful thing to tell someone whose `.git/config` names a
+    // program Codeep will not run through.
+    let hooksDir;
+    try {
+        hooksDir = deps.resolveHooksDir(process.cwd());
+    }
+    catch (error) {
+        deps.write(`${error instanceof Error ? error.message : String(error)}\n` +
+            'Fix that config (or run the hook installer yourself) and try again.');
+        return 1;
+    }
     if (!hooksDir) {
         deps.write('Not a git repository — run `codeep hook` inside a repo.');
         return 1;

package/dist/utils/headlessReview.js

@@ -227,6 +227,7 @@ export async function runFixPlan(plan, context) {
             return `${summariseFixPlan(plan)} No API key is configured for the current provider, so the fix agent could not start.`;
         }
         const { runAgent } = await import('./agent.js');
+        const { NO_CONFIRMER_REFUSAL } = await import('./toolExecution.js');
         // No cast here. `as never` on this call once hid the fact that
         // personalityOverride did not exist, which would have run the CI fix with
         // no boundary at all while the tests happily asserted otherwise.
@@ -239,24 +240,44 @@ export async function runFixPlan(plan, context) {
             // the plan, which buildFixPlan caps, and the action's wall-clock.
             maxIterations: 25,
         });
+        // `result === 'success'` matters: a write the agent ATTEMPTED is logged
+        // whether or not it happened, so a refused `.git/config` was being
+        // reported to CI as a file this run edited — the exact opposite of the
+        // truth, and the file is not in the diff for anyone to check against.
         const edited = new Set(result.actions
-            .filter(a => a.type === 'write' || a.type === 'edit')
+            .filter(a => (a.type === 'write' || a.type === 'edit') && a.result === 'success')
             .map(a => a.target));
         const activity = describeAgentActivity(result.actions);
+        // A headless run passes no permission callback, so a write to a file that
+        // decides what runs later — `.git/config`, a hook, an MCP server list —
+        // is refused rather than done unasked. That is the right answer for CI:
+        // an unattended run must not be the thing that installs a hook. But the
+        // refusal only ever reached the model, so the run looked like it had
+        // simply chosen not to fix that finding, and the one action a human has
+        // to take was in nobody's log. Name it in the summary, which is what the
+        // action prints. An opt-in flag was the alternative and is worse: it
+        // would exist to be set in a YAML file once and then never read again.
+        const refused = [...new Set(result.actions
+                .filter(a => a.result === 'error' && a.details?.includes(NO_CONFIRMER_REFUSAL))
+                .map(a => a.target))];
+        const refusalNote = refused.length
+            ? ` It was refused ${refused.length} write${refused.length === 1 ? '' : 's'} to ${refused.join(', ')}: ` +
+                'those files decide what runs later, and a headless run has nobody to confirm them. Edit them yourself.'
+            : '';
         const editedList = `Edited ${edited.size} file${edited.size === 1 ? '' : 's'}: ${[...edited].join(', ')}.`;
         if (!result.success) {
             // The run did its work and the checks after it failed. The edits are in
             // the working tree all the same, so name them next to the checks.
             if (result.failedChecks?.length) {
                 const changed = edited.size > 0 ? editedList : activity;
-                return `${summariseFixPlan(plan)} ${changed} These checks still fail afterwards: ${result.failedChecks.join(', ')}.`;
+                return `${summariseFixPlan(plan)} ${changed}${refusalNote} These checks still fail afterwards: ${result.failedChecks.join(', ')}.`;
             }
-            return `${summariseFixPlan(plan)} The run did not finish: ${result.error ?? 'unknown error'}. ${activity}`;
+            return `${summariseFixPlan(plan)} The run did not finish: ${result.error ?? 'unknown error'}. ${activity}${refusalNote}`;
         }
         if (edited.size === 0) {
-            return `${summariseFixPlan(plan)} Nothing was changed. ${activity}`;
+            return `${summariseFixPlan(plan)} Nothing was changed. ${activity}${refusalNote}`;
         }
-        return `${summariseFixPlan(plan)} ${editedList}`;
+        return `${summariseFixPlan(plan)} ${editedList}${refusalNote}`;
     }
     catch (error) {
         // A missing key or an unreachable provider must not fail the review. The

package/dist/utils/personalities.js

@@ -39,7 +39,7 @@ import { basename, join } from 'path';
 import { homedir } from 'os';
 import { leadsOutsideProject } from './projectPaths.js';
 import { config } from '../config/index.js';
-import { getProvider } from '../config/providers.js';
+import { getProvider, replacementModelFor } from '../config/providers.js';
 const CAPABILITIES = new Set([
     'files', 'terminal', 'tests', 'git', 'web', 'mcp',
 ]);
@@ -126,7 +126,13 @@ function exactModelPreference(preference) {
         return null;
     const providerId = value.slice(0, slash).trim();
     const model = value.slice(slash + 1).trim();
-    return providerId && model ? { providerId, model } : null;
+    if (!providerId || !model)
+        return null;
+    // A bot written before a vendor retired its model (or before Codeep stopped
+    // offering one, like `openai/gpt-6-astra`) names an id the picker no longer
+    // has, and the exact check below would make the whole bot unavailable. Map it
+    // the way the startup migration and applyProfile map a stored id.
+    return { providerId, model: replacementModelFor(providerId, model) ?? model };
 }
 /** Whether a structured bot's model field satisfies the portable v1 contract. */
 export function isPersonalityModelPreferenceValid(personality) {

package/dist/utils/shell.d.ts

@@ -35,6 +35,114 @@ export declare function validateCommand(command: string, args: string[], options
     valid: boolean;
     reason?: string;
 };
+/**
+ * The environment a validated command runs in.
+ *
+ * `git` is on ALLOWED_COMMANDS, so a skill's shell line, a `!` command or the
+ * agent's own execute_command reaches git with whatever the repository put in
+ * its `.git/config` — and several of those settings make git RUN a program:
+ * a `filter.<driver>.clean` fires during the index refresh `git status` does,
+ * before anything looks like it executed code. Route git through the same
+ * hardening Codeep's own git calls use.
+ *
+ * Hooks are deliberately left alone here. The command was approved as
+ * written, so `git commit` through this path runs the repository's
+ * pre-commit hook exactly as it would in the user's terminal.
+ *
+ * A caller's own `env` goes in as the BASE rather than on top of the result:
+ * spread afterwards, their GIT_CONFIG_COUNT would replace ours and silently
+ * drop every override above their count.
+ *
+ * The bare name is the whole test because it has to be: validateCommand()
+ * only lets a command through when ALLOWED_COMMANDS holds it, and that set
+ * holds `git`, not `/usr/bin/git`. A path-spelled git never reaches here.
+ *
+ * The directory scanned comes from the ARGV, not from the spawn's cwd: `git
+ * -C vendor/lib status` reads the vendored checkout's config, so that is the
+ * config that has to be neutralised. The argv forms that redirect git
+ * somewhere this cannot follow (`--git-dir`, `--work-tree`, `--exec-path`,
+ * `--config-env`) never get here — validateCommand() refuses them.
+ *
+ * Throws `GitHardeningError` when the repository's config cannot be scanned —
+ * both runners below turn that into a failed CommandResult, because a refusal
+ * is this command's own failure and the user reads it as such.
+ *
+ * EXPORTED, and this signature is the contract, because the ACP terminal
+ * path spawns its own children and has to harden the SAME repository this
+ * does. Call it with the parsed command, its argv, the cwd the spawn will
+ * get and the caller's own env in `options.env`, and hand the result to the
+ * spawn as `env` — do not spread anything over it, or a later
+ * GIT_CONFIG_COUNT replaces ours and silently drops every override above it.
+ * The argv is not optional there: `git -C vendor/lib status` scans
+ * `vendor/lib`, and a caller that passes only the cwd hardens the wrong
+ * repository. A shell LINE rather than an argv belongs to shellCommandEnv()
+ * below instead. Both throw, and a refusal that escapes a promise executor
+ * never settles it.
+ */
+export declare function commandEnv(command: string, args: string[], cwd: string, options?: CommandOptions): NodeJS.ProcessEnv;
+/**
+ * The environment for a whole SHELL COMMAND LINE that may reach git.
+ *
+ * commandEnv() above can check a parsed binary name; a line handed to a shell
+ * can reach git from anywhere inside it — `cd sub && git status`, `make && git
+ * commit`, `foo | git apply` — so it needs its own entry point. This is that
+ * entry point for the callers that spawn with `shell: true`: the skill runner
+ * in src/acp/commands.ts and the one in src/renderer/agentExecution.ts, both
+ * of which used to reach git raw. A hostile `gpg.program` that createCommit
+ * neutralises still executed through those two spawns (proven, git 2.54).
+ *
+ * This is the ONE helper for that job — an earlier cut of this hotfix also
+ * had a `hardenedShellEnv()` in utils/toolExecution.ts, which hardened every
+ * skill step unconditionally and therefore refused an `echo` in a repository
+ * whose config cannot be scanned. Keep it one: two helpers with two different
+ * answers to "does a refusal stop this line?" is how one of them ends up
+ * wrong and unused.
+ *
+ * The contract, since those two call sites are not this file's to edit:
+ *
+ * - Pass the command line, the cwd the shell will get and any env of your
+ *   own, and hand the RESULT to the spawn as `env`. Do not spread anything
+ *   over it — a later `GIT_CONFIG_COUNT` replaces ours and silently drops
+ *   every override above it.
+ * - It THROWS `GitHardeningError` when the repository's config cannot be
+ *   scanned, or names a program no override can switch off. Catch it and fail
+ *   the command with `error.message`, which is written for the user. Letting
+ *   it escape a `spawnSync` call site turns a refusal into a crash; letting
+ *   it escape inside a promise executor leaves the caller hanging.
+ * - Hooks are left alone, as they are for executeCommand(): the line was
+ *   approved as written, so `git commit` in it runs the repository's
+ *   pre-commit hook exactly as it would in the user's terminal.
+ * - A line that cannot reach git comes back unhardened, so a repository with
+ *   an unreadable config does not also break `echo`. That is also why a
+ *   refusal never reaches a non-git line: an `echo` must not stop working
+ *   because some repository in the project sets `remote.origin.uploadpack`.
+ *
+ * WHAT THIS CAN AND CANNOT PROMISE, because a shell line is not an argv:
+ *
+ * - Scanned: the repository at `cwd`, AND every submodule of it — the ones
+ *   its index records as gitlinks and the ones its config records by name,
+ *   wherever each keeps its git directory (see listSubmoduleConfig in
+ *   utils/git.ts). Every key in REPO_EXECUTING_RULES
+ *   that any of them sets is neutralised, and because the overrides ride in
+ *   the ENVIRONMENT rather than in an argv, they apply wherever in the line
+ *   git ends up — so `cd vendor/lib && git add` is covered in full when
+ *   `vendor/lib` is a submodule, which is the shape a skill step usually has.
+ * - Not scanned: a repository that is not `cwd` and not one of its
+ *   submodules — an independent checkout under `vendor/`, a sibling clone,
+ *   anywhere a `make` target cds to. There is no way to know where a shell
+ *   line ends up without running it, so this does not pretend to. What still
+ *   covers those is the always-on GIT_EXECUTING_CONFIG layer, which is why
+ *   `core.fsmonitor` is blanket there rather than scope-aware. The gap is the
+ *   keys GIT_CONFIG_* cannot wildcard — `filter.*` above all — in an
+ *   unrelated repository below the one scanned. Proven with git 2.54: `cd
+ *   vendor/lib && git status`, with `vendor/lib` a plain nested clone rather
+ *   than a submodule, did not run the nested `core.fsmonitor` and did run the
+ *   nested `filter.<d>.clean`.
+ * - executeCommand()'s argv path has no such gap: it reads `-C` out of the
+ *   argv and scans where git will actually run, and refuses `--git-dir` /
+ *   `--work-tree` / `--exec-path` / `--config-env` outright.
+ */
+export declare function shellCommandEnv(commandLine: string, cwd: string, env?: Record<string, string>): NodeJS.ProcessEnv;
 /**
  * Execute a shell command with safety checks
  */