fix(#6358): load sandbox hook settings via --settings flag by fullsend-ai-coder[bot] · Pull Request #6405 · fullsend-ai/fullsend

fullsend-ai-coder · 2026-08-20T10:55:09Z

Summary

Sandbox tool hooks (Tirith, SSRF, canary, secret redaction, unicode normalization, context suppression, tool allowlist) were silently never loaded by Claude Code in production runs. installClaudeHooks wrote hook wiring to /sandbox/workspace/.claude/settings.json, but buildRunCommand starts the CLI from /sandbox/workspace/<repo>. Claude Code only reads project settings from <cwd>/.claude/settings.json — the hooks directory was a sibling, not a parent, so the settings were never found.

Changes

Move hooks to runner-owned config directory: Hook scripts now live at /sandbox/claude-config/hooks/ and settings at /sandbox/claude-config/hooks.json — co-located under the runner-owned directory, outside the agent-writable workspace tree
Pass settings via --settings flag: buildRunCommand appends --settings /sandbox/claude-config/hooks.json when HooksSettingsPath is set in RunParams, which run.go populates when security is enabled. --settings takes precedence over project/local settings
Golden tests: Three new tests verify --settings presence, absence, and quote escaping. The no-double-spaces table test updated to cover the new flag
Documentation: docs/runtimes.md workspace layout diagram updated to reflect the new paths

Testing

go test ./internal/runtime/... — all tests pass including new golden tests
go test ./internal/security/... — all tests pass
go vet ./... — clean
go build ./... — clean
buildRunCommand at 100% coverage
Pre-commit could not run (sandbox network policy); post-script runs authoritatively

Follow-up

Repo-owned <repo>/.claude/settings.json hooks are still loaded from <cwd> by Claude Code. The --settings flag ensures runner hooks take precedence, but a malicious repo could add its own hooks. A follow-up issue should assess whether to scan or disable repo-owned hooks.

Closes #6358

Post-script verification

Branch is not main/master (agent/6358-hooks-settings-path)
Secret scan passed (gitleaks — 2e78d663bb7aa15db58e97e83dcf9d27eacdc0ac..HEAD)
PR body secret scan passed (gitleaks — no-git)

github-actions · 2026-08-20T10:56:59Z

Site preview

Preview: https://1d442f0d-site.fullsend-ai.workers.dev

Commit: b07a630b39316c4fd61363ef7975bd3767d469d8

fullsend-ai-review · 2026-08-20T10:57:03Z

🤖 Finished Review · ✅ Success · Started 10:57 AM UTC · Completed 11:15 AM UTC

Commit: 16432d1 · View workflow run →

codecov · 2026-08-20T10:59:09Z

Codecov Report

❌ Patch coverage is 91.66667% with 1 line in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
internal/runtime/claude.go	90.00%	1 Missing ⚠️

📢 Thoughts on this report? Let us know!

fullsend-ai-review · 2026-08-20T11:15:21Z

Review

Findings

Medium

[Malicious hook injection via repo-controlled settings] internal/runtime/claude.go — The PR correctly loads runner-owned hooks via --settings, which takes precedence over project/local settings for key collisions. However, a target repo could still bundle its own .claude/settings.json with additional hook definitions. Depending on Claude Code's merge semantics for hooks across settings layers, repo-controlled hooks could run alongside the runner-owned security hooks, allowing a malicious repo to intercept tool I/O or interfere with security hook execution. The PR body acknowledges this risk as a follow-up concern.
Remediation: Strip or overwrite .claude/settings.json from the target repo before agent execution, or verify that --settings fully replaces (not merges) hook definitions from other settings sources.
[Hook config file writable by agent] internal/security/hooks.go — Hook scripts and hooks.json are installed to /sandbox/claude-config/hooks/ but are not made read-only after bootstrap. Since the agent runs as the same sandbox user (via openshell), it could modify or disable security hooks during execution. The description of this directory as "runner-owned" is accurate in intent but not enforced by file permissions.
Remediation: Make /sandbox/claude-config/hooks/ and hooks.json read-only (e.g., chmod a-w) after installClaudeHooks completes.

Low

[Security hooks silently skipped when SecurityEnabled is false] internal/cli/run.go:1517 — HooksSettingsPath is only set when h.SecurityEnabled() is true. The default is fail-closed (enabled), which is correct. Informational only.
[follow-up-tracking] — Acceptance criterion docs: add agent infrastructure problem document #5 from issue Sandbox tool hooks are never loaded: settings.json is written to /sandbox/workspace/.claude but Claude Code runs from /sandbox/workspace/<repo> #6358 ("Assess repo-owned hook exposure and file a follow-up") is acknowledged in the PR body but no follow-up issue has been filed yet.
[Naming consistency (rename residue)] internal/runtime/claude.go:386 — Variable tmpSettings and error messages "creating temp settings file" / "writing settings" were not updated to match the rename to GenerateHooksConfig and hooks.json. Other references in the same function (temp file prefix, upload error message) were updated.

Previous run

Review

Findings

Medium

[hook tamper resistance] internal/runtime/claude.go:339 — Hook scripts are uploaded to /sandbox/claude-config/hooks/ via sandbox.Upload (SCP after sandbox creation). Per ADR 0032, files delivered after Landlock policy activation land on writable paths — only files baked into the container image at build time can be placed on Landlock-protected read-only paths. The agent can still overwrite or delete its own security hook scripts and hooks.json during execution. The improvement over the prior location (/sandbox/workspace/.claude/) is real — hooks are no longer under the working directory tree where Claude Code discovers project-level settings — but tamper resistance is logical ownership, not OS-enforced.
Remediation: Document this limitation explicitly. For stronger enforcement, bake hook scripts into the sandbox image at build time on a Landlock-protected path, or verify hook file integrity (checksum) before agent execution.

Low

[fail-open analysis] internal/cli/run.go:1516 — SecurityEnabled() defaults to true when Security is nil (fail-closed). No fail-open path exists. The --settings flag is correctly gated behind this check.
[input validation] internal/runtime/claude.go:306 — HooksSettingsPath originates from a compile-time constant (security.SandboxHooksSettings) and is sanitized via the same single-quote escaping pattern used for other CLI flags. No injection vector exists.
[acceptance-criteria-gap] docs/runtimes.md — Issue AC4 references restoring security matrix checkmarks, but they were never degraded by refactor(runtime): make sandbox tool hooks and runner capabilities runtime-neutral #6355. The end state is correct.
[acceptance-criteria-gap] — Issue AC5 (repo-owned <repo>/.claude/settings.json hooks exposure) is acknowledged in the PR body as needing a follow-up, but no follow-up issue has been filed yet.

Previous run (2)

Review

Findings

Medium

[test-integrity] e2e/behaviour/features/dispatch/hooks-loaded.feature:1 — The e2e scenario claims to verify that a PreToolUse hook fires end-to-end, catching the "silently not loaded" class of regression. However, it uses a dummy agent (DummyRuntime), which executes url_get via direct curl in the sandbox shell — it never invokes Claude Code, so PreToolUse hooks cannot fire. The url_get to 169.254.169.254 will fail due to the sandbox's default-deny network policy, not because the SSRF hook blocked a Claude Code tool call. The test would pass identically whether hooks are loaded or not.
Remediation: Use ClaudeRuntime so PreToolUse hooks fire, or reframe the test's description to match what it actually verifies (sandbox network policy blocks metadata endpoint access). The golden tests (TestBuildRunCommand_WithHooksSettings) already verify the --settings flag is present in the command string.
[acceptance-criteria-gap] Issue Sandbox tool hooks are never loaded: settings.json is written to /sandbox/workspace/.claude but Claude Code runs from /sandbox/workspace/<repo> #6358 acceptance criterion docs: add agent infrastructure problem document #5 requires assessing repo-owned <repo>/.claude/settings.json hooks exposure and filing a follow-up. The PR body acknowledges the risk ("a malicious repo could add its own hooks") and recommends a follow-up, but no follow-up issue has been filed.
Remediation: File the follow-up issue before merging, or add its number to the PR body.

Low

[struct-field-ordering] internal/runtime/runtime.go — HooksSettingsPath is placed between Debug and Timeout in RunParams. The existing field ordering groups path fields together (RepoDir, FullsendDir, PluginDirs). Moving HooksSettingsPath after PluginDirs would be more consistent with the grouping convention.
[test-helper-consistency] internal/runtime/claude_test.go:214 — TestBuildRunCommand_NoDoubleSpaces switches from testRunCommandWithEffort helper to direct buildRunCommand(RunParams{...}) calls, while neighboring tests continue using the helpers. This is a reasonable adaptation (the helpers don't accept HooksSettingsPath), but creates a minor inconsistency.

Previous run (3)

Review

Findings

Medium

[stale-reference] docs/architecture.md:172 — References "Tool permissions are injected as a host-managed .claude/settings.json" but this PR moves hook wiring to hooks.json under the runner-owned claude-config/ directory, loaded via --settings. The parenthetical now describes a path and mechanism that no longer exist.
Remediation: Update to reference hooks.json loaded via --settings.
[stale-reference] docs/guides/dev/cli-internals.md:432 — The command example for buildClaudeCommand() does not include the --settings flag added by this PR. The function name is also stale (buildClaudeCommand vs actual buildRunCommand).
Remediation: Add --settings '{hooksSettingsPath}' (conditional) to the example and update the function name.
[security hook bypass via target repo project settings] internal/runtime/claude.go:306 — The --settings flag loads runner-owned hook wiring, but a target repo's own .claude/settings.json (loaded from cwd) could also define hooks. If Claude Code merges hook arrays rather than replacing, a malicious repo could inject hooks alongside the security hooks. The PR body acknowledges this as a follow-up.
Remediation: Verify --settings fully replaces project-level hooks; file a follow-up issue for repo-owned hook assessment.

Low

[naming-consistency] internal/runtime/claude.go — The temp file pattern in installClaudeHooks remains fullsend-settings-*.json after the rename to hooks-centric naming. Cosmetic only (temp files are deleted immediately).
[struct-field-ordering] internal/runtime/runtime.go:33 — HooksSettingsPath is placed between Debug and Timeout, splitting the execution-config group. Ordering is self-consistent across usage sites.

Previous run (4)

Review

Findings

Medium

[security-hook-bypass] internal/runtime/claude.go:339 — Repo-owned hooks can run alongside runner-owned security hooks, potentially interfering with them. A target repo can include its own .claude/settings.json with hooks definitions that Claude Code loads from <cwd>/.claude/settings.json as project-level settings. While --settings gives the runner hooks precedence, project-level hooks are additive — a malicious repo could install hooks that interfere with the security hook chain. This risk is pre-existing and not introduced by this PR; the PR strictly improves the status quo (hooks were silently never loaded before). The PR body acknowledges this and recommends a follow-up.
Remediation: File a follow-up issue to evaluate whether repo-level hook definitions should be blocked or overwritten before the agent starts.

Low

[acceptance-criteria-gap] Issue Sandbox tool hooks are never loaded: settings.json is written to /sandbox/workspace/.claude but Claude Code runs from /sandbox/workspace/<repo> #6358 acceptance criterion docs: add agent infrastructure problem document #5 states "Assess the repo-owned <repo>/.claude/settings.json hooks exposure and file a follow-up if needed." The PR body assesses the risk and recommends a follow-up but does not reference a filed follow-up issue.
[stale-diagram] docs/guides/dev/cli-internals.md:424 — The sandbox execution diagram references buildClaudeCommand() but the actual function is buildRunCommand(). The diagram also omits the new conditional --settings flag added by this PR.
Remediation: Update the function name and add --settings {hooksSettings} to the flag listing.
[fail-open] internal/cli/run.go:1495 — When h.SecurityEnabled() returns false, no security hooks are loaded. This is intentional and SecurityEnabled() defaults to true, so this is not a fail-open in the default case.
[naming-coherence] internal/security/hooks.go:47 — claudeSettings and GenerateClaudeSettings names reference "settings" while the output file is now hooks.json. The naming still works (it generates a Claude Code settings structure for --settings) but the mismatch may cause confusion.

Previous run (5)

Review

Findings

Medium

[API contract] internal/runtime/claude.go — The fix relies on Claude Code's --settings flag merging additively with {CLAUDE_CONFIG_DIR}/settings.json (which stores enabledPlugins from bootstrapPlugins). If --settings replaces the user-level settings entirely, plugin loading would be silently disabled. No in-repo test covers the "plugins + hooks both active" scenario.
Remediation: Verify Claude Code CLI --settings semantics and consider adding a test confirming plugins remain functional when --settings is also passed.

Low

[security control bypass] internal/runtime/claude.go:340 — Hook scripts and hooks.json are writable by the same sandbox UID that runs the agent. No chmod/chown post-upload. A compromised agent could overwrite hook scripts to disable security controls. The comment "outside the agent-writable workspace tree" overstates the filesystem-level protection. Not a regression — the old location had the same vulnerability.
[scope-vs-authorization] — Issue Sandbox tool hooks are never loaded: settings.json is written to /sandbox/workspace/.claude but Claude Code runs from /sandbox/workspace/<repo> #6358 acceptance criterion 5 requires filing a follow-up issue to assess repo-owned .claude/settings.json hooks exposure. The PR body acknowledges this but the follow-up issue does not appear to have been filed.
[stale-documentation] docs/guides/dev/cli-internals.md:424 — The command template does not include the new --settings flag added by this PR.
[stale-documentation] docs/guides/dev/cli-internals.md:401 — The bootstrap section lists security hooks as uploaded to /sandbox/workspace, but they now go to /sandbox/claude-config/hooks/.

Labels: PR modifies sandbox security hook installation (internal/security/hooks.go) and runner CLI/runtime (internal/cli/run.go, internal/runtime/)

Previous run (6)

Review

Findings

Medium

[stale-reference] internal/security/hooks.go:46 — Two stale comments remain after the path relocation: (a) the claudeSettings struct comment says "represents the .claude/settings.json structure" and (b) the GenerateClaudeSettings docstring says "produces a .claude/settings.json". Both now describe hooks.json content written to SandboxHooksSettings under the runner-owned config directory.
Remediation: Update struct comment to "represents the hooks.json structure for Claude Code hook wiring" and the function docstring to "produces a hooks.json with security hooks..."
[stale-reference] internal/cli/run.go:1773 — Comment in bootstrapCommon says "Claude hook scripts live under workspace/.claude/" but this PR moves hook scripts to claude-config/hooks/ (SandboxClaudeConfig + "/hooks").
Remediation: Update comment to reference claude-config/hooks/.
[scope-gap] Issue Sandbox tool hooks are never loaded: settings.json is written to /sandbox/workspace/.claude but Claude Code runs from /sandbox/workspace/<repo> #6358 acceptance criterion 3 requires an e2e/behaviour test or --debug hooks capture demonstrating hooks actually fire at runtime. The PR includes golden/unit tests for command string construction but no evidence that hooks load and execute in the sandbox.

Low

[scope-gap] Issue Sandbox tool hooks are never loaded: settings.json is written to /sandbox/workspace/.claude but Claude Code runs from /sandbox/workspace/<repo> #6358 acceptance criterion 5 is partially addressed — the PR body describes the repo-owned hooks exposure risk — but no follow-up issue has been filed to track the assessment.

maruiz93 · 2026-08-20T11:50:02Z

[High] The issue acceptance criteria require "a behaviour/e2e or functional check exercises one blocking hook end-to-end under the pinned CLI." The golden tests added here verify the --settings flag appears in the command string, but they wouldn't have caught the original bug — the wiring was correct, the location was wrong. A Gherkin behaviour test under e2e/behaviour/features/ that configures a blocking hook, runs an agent, and asserts the hook fires (N > 0 in "Found N total hooks in registry") would catch this class of "silently not loaded" regression.

Hook scripts and hooks.json are writable by the agent process after installation. Since Claude Code runs with --dangerously-skip-permissions, a prompt-injected agent could overwrite hook scripts between tool invocations, disabling security controls. chmod alone doesn't help — the agent runs as the same user. The real fix is landlock-based path protection, tracked in NVIDIA/OpenShell#1268 and #6404.

[Low] internal/cli/run.go:1773 — stale comment says hook scripts live under workspace/.claude/ but they now live under claude-config/hooks/.

maruiz93 · 2026-08-20T11:51:38Z

/fs-fix Address the review comments: add a Gherkin behaviour test, fix the stale comments in run.go:1773, hooks.go:46, and hooks.go:61.

fullsend-ai-coder · 2026-08-20T11:53:44Z

🤖 Finished Fix · ✅ Success · Started 11:53 AM UTC · Completed 12:05 PM UTC

Commit: 16432d1 · View workflow run →

- run.go:1773: update comment to reference claude-config/hooks/ instead of the old workspace/.claude/ path - hooks.go:46: update claudeSettings comment to reference hooks.json instead of .claude/settings.json - hooks.go:61: update GenerateClaudeSettings docstring to reference hooks.json instead of .claude/settings.json - Add hooks-loaded.feature: Gherkin behaviour test that dispatches a custom harness, attempts to fetch a cloud metadata endpoint (169.254.169.254), and asserts the SSRF PreToolUse hook blocks it. Catches the "silently not loaded" regression class. Addresses review feedback on #6405

fullsend-ai-coder · 2026-08-20T12:05:12Z

🔧 Fix agent — iteration 1 (human-triggered)

Addressed all 4 review findings: fixed 3 stale comments referencing old hook paths (.claude/settings.json, workspace/.claude/) and added a Gherkin behaviour test (hooks-loaded.feature) that verifies the SSRF PreToolUse hook fires end-to-end when hooks are loaded via --settings.

Fixed (4):

stale comment in run.go:1773 (internal/cli/run.go): Updated comment from 'workspace/.claude/' to 'claude-config/hooks/' to reflect the new hook script location after this PR's path relocation
stale comment in hooks.go:46 (claudeSettings struct) (internal/security/hooks.go): Updated claudeSettings struct comment from 'represents the .claude/settings.json structure' to 'represents the hooks.json structure for Claude Code hook wiring'
stale comment in hooks.go:61 (GenerateClaudeSettings docstring) (internal/security/hooks.go): Updated GenerateClaudeSettings docstring from 'produces a .claude/settings.json' to 'produces a hooks.json' to reflect the new output file name
missing Gherkin behaviour test for hook loading (e2e/behaviour/features/dispatch/hooks-loaded.feature): Added hooks-loaded.feature that dispatches a custom harness, attempts to fetch the cloud metadata endpoint (169.254.169.254), and asserts the SSRF PreToolUse hook blocks it. This catches the 'silently not loaded' regression class where hook wiring exists but Claude Code never reads it.

Tests: passed

Next steps:

/fs-review — request a re-review of the changes
/fs-fix <your instruction> — run another fix pass with specific guidance
Push commits directly — review re-runs automatically on push
_{Updated by fullsend fix agent}

fullsend-ai-review · 2026-08-20T12:07:12Z

🤖 Finished Review · ✅ Success · Started 12:07 PM UTC · Completed 12:25 PM UTC

Commit: 45ccde0 · View workflow run →

maruiz93 · 2026-08-20T13:46:40Z

/fs-fix Rebase onto main and fix any coverage gaps.

fullsend-ai-coder · 2026-08-20T13:48:20Z

🤖 Finished Fix · ✅ Success · Started 1:48 PM UTC · Completed 1:59 PM UTC

Commit: 45ccde0 · View workflow run →

fullsend-ai-coder · 2026-08-20T13:59:05Z

🔧 Fix agent — iteration 2 (human-triggered)

Rebased branch onto origin/main (clean, no conflicts). Added 2 tests for installClaudeHooks to close the patch coverage gap — function went from 0% to 59.6% coverage. All changed lines in the diff (hooksDir, mkdirCmd format, remotePath format, Upload target) are now exercised. Pre-existing CLI test failures (TestStartFetchService, TestPostScriptEnv) confirmed present on main, not caused by this PR. internal/cli/run.go is in Codecov's ignore list.

Fixed (2):

rebase onto main: Rebased branch onto origin/main. The rebase applied cleanly with no conflicts (2 commits from main: renovate/experiments-digest merge).
fix coverage gaps (internal/runtime/claude_test.go): Added TestInstallClaudeHooks_HappyPath and TestInstallClaudeHooks_OpenshellNotInPath to cover the installClaudeHooks function, which had 0% coverage. The happy path test uses a stub openshell binary (matching existing Bootstrap test patterns) and exercises all changed lines (hooksDir assignment, mkdir format, remotePath format, Upload call with SandboxHooksSettings). Coverage rose from 0% to 59.6% for this function.

Tests: passed

Decision points

Used stub openshell pattern for installClaudeHooks test rather than refactoring to use interfaces (alternatives: Refactor sandbox.Exec/Upload to interface for testability, Test only via Bootstrap integration; rationale: Matches the existing test pattern used by TestClaudeRuntime_Bootstrap_AgentNameDest and other tests in this file. Stub openshell is the established convention for testing sandbox-dependent code.)

Next steps:

/fs-review — request a re-review of the changes
/fs-fix <your instruction> — run another fix pass with specific guidance
Push commits directly — review re-runs automatically on push
_{Updated by fullsend fix agent}

- run.go:1773: update comment to reference claude-config/hooks/ instead of the old workspace/.claude/ path - hooks.go:46: update claudeSettings comment to reference hooks.json instead of .claude/settings.json - hooks.go:61: update GenerateClaudeSettings docstring to reference hooks.json instead of .claude/settings.json - Add hooks-loaded.feature: Gherkin behaviour test that dispatches a custom harness, attempts to fetch a cloud metadata endpoint (169.254.169.254), and asserts the SSRF PreToolUse hook blocks it. Catches the "silently not loaded" regression class. Addresses review feedback on #6405

The installClaudeHooks function had 0% test coverage. Two new tests exercise the happy path (stub openshell) and the error path (missing openshell), bringing the function to ~60% coverage and ensuring the changed hook-path and settings-path lines are covered. Addresses review feedback on #6405

fullsend-ai-review · 2026-08-20T14:01:15Z

🤖 Finished Review · ✅ Success · Started 2:01 PM UTC · Completed 2:19 PM UTC

Commit: 0a16c18 · View workflow run →

fullsend-ai-review · 2026-08-21T10:36:03Z

🤖 Finished Review · ✅ Success · Started 10:36 AM UTC · Completed 10:55 AM UTC

Commit: f3153a0 · View workflow run →

- run.go:1773: update comment to reference claude-config/hooks/ instead of the old workspace/.claude/ path - hooks.go:46: update claudeSettings comment to reference hooks.json instead of .claude/settings.json - hooks.go:61: update GenerateClaudeSettings docstring to reference hooks.json instead of .claude/settings.json - Add hooks-loaded.feature: Gherkin behaviour test that dispatches a custom harness, attempts to fetch a cloud metadata endpoint (169.254.169.254), and asserts the SSRF PreToolUse hook blocks it. Catches the "silently not loaded" regression class. Addresses review feedback on #6405

The installClaudeHooks function had 0% test coverage. Two new tests exercise the happy path (stub openshell) and the error path (missing openshell), bringing the function to ~60% coverage and ensuring the changed hook-path and settings-path lines are covered. Addresses review feedback on #6405

…rateHooksConfig The struct and function names still referenced "claude settings" after the output file was renamed to hooks.json. Rename to hooksConfig and GenerateHooksConfig to match the actual artifact, and add a test covering the hooks.json upload error path to close the codecov/patch coverage gap. Addresses review feedback on #6405

- docs/architecture.md: update parenthetical from ".claude/settings.json" to "hooks.json loaded via --settings" - docs/guides/dev/cli-internals.md: fix function name from buildClaudeCommand() to buildRunCommand() and add conditional --settings flag to the command diagram - internal/runtime/claude.go: rename temp file pattern from fullsend-settings-*.json to fullsend-hooks-*.json for consistency with the hooksConfig/GenerateHooksConfig rename Addresses review feedback on #6405

fullsend-ai-review · 2026-08-21T11:00:30Z

🤖 Finished Review · ✅ Success · Started 11:00 AM UTC · Completed 11:13 AM UTC

Commit: b924d2e · View workflow run →

- run.go:1773: update comment to reference claude-config/hooks/ instead of the old workspace/.claude/ path - hooks.go:46: update claudeSettings comment to reference hooks.json instead of .claude/settings.json - hooks.go:61: update GenerateClaudeSettings docstring to reference hooks.json instead of .claude/settings.json - Add hooks-loaded.feature: Gherkin behaviour test that dispatches a custom harness, attempts to fetch a cloud metadata endpoint (169.254.169.254), and asserts the SSRF PreToolUse hook blocks it. Catches the "silently not loaded" regression class. Addresses review feedback on #6405

The installClaudeHooks function had 0% test coverage. Two new tests exercise the happy path (stub openshell) and the error path (missing openshell), bringing the function to ~60% coverage and ensuring the changed hook-path and settings-path lines are covered. Addresses review feedback on #6405

…rateHooksConfig The struct and function names still referenced "claude settings" after the output file was renamed to hooks.json. Rename to hooksConfig and GenerateHooksConfig to match the actual artifact, and add a test covering the hooks.json upload error path to close the codecov/patch coverage gap. Addresses review feedback on #6405

- docs/architecture.md: update parenthetical from ".claude/settings.json" to "hooks.json loaded via --settings" - docs/guides/dev/cli-internals.md: fix function name from buildClaudeCommand() to buildRunCommand() and add conditional --settings flag to the command diagram - internal/runtime/claude.go: rename temp file pattern from fullsend-settings-*.json to fullsend-hooks-*.json for consistency with the hooksConfig/GenerateHooksConfig rename Addresses review feedback on #6405

fullsend-ai-review · 2026-08-21T11:18:41Z

🤖 Review · ⚠️ Cancelled · Started 11:18 AM UTC · Ended 11:31 AM UTC

Commit: c5ad996 · View workflow run →

installClaudeHooks wrote hook wiring to /sandbox/workspace/.claude/settings.json, but buildRunCommand starts Claude Code from /sandbox/workspace/<repo>. Claude Code only reads project settings from <cwd>/.claude/settings.json, so the security hooks were silently never loaded. Move hook scripts and settings to /sandbox/claude-config/ (the runner-owned config directory, outside the agent-writable workspace tree) and pass the settings file via --settings in buildRunCommand. --settings takes precedence over project/local settings, ensuring the runner's security hooks are always active. Changes: - security.SandboxHooksDir → /sandbox/claude-config/hooks - Add security.SandboxHooksSettings → /sandbox/claude-config/hooks.json - installClaudeHooks writes to the new paths - buildRunCommand appends --settings when HooksSettingsPath is set - run.go populates HooksSettingsPath when security is enabled - Golden tests for --settings presence/absence/quoting - docs/runtimes.md workspace layout updated Note: pre-commit could not run (sandbox network policy blocks git fetch for hook environment setup). go vet and go test passed. The post-script runs authoritative pre-commit on the runner. Closes #6358

- run.go:1773: update comment to reference claude-config/hooks/ instead of the old workspace/.claude/ path - hooks.go:46: update claudeSettings comment to reference hooks.json instead of .claude/settings.json - hooks.go:61: update GenerateClaudeSettings docstring to reference hooks.json instead of .claude/settings.json - Add hooks-loaded.feature: Gherkin behaviour test that dispatches a custom harness, attempts to fetch a cloud metadata endpoint (169.254.169.254), and asserts the SSRF PreToolUse hook blocks it. Catches the "silently not loaded" regression class. Addresses review feedback on #6405

The installClaudeHooks function had 0% test coverage. Two new tests exercise the happy path (stub openshell) and the error path (missing openshell), bringing the function to ~60% coverage and ensuring the changed hook-path and settings-path lines are covered. Addresses review feedback on #6405

…rateHooksConfig The struct and function names still referenced "claude settings" after the output file was renamed to hooks.json. Rename to hooksConfig and GenerateHooksConfig to match the actual artifact, and add a test covering the hooks.json upload error path to close the codecov/patch coverage gap. Addresses review feedback on #6405

- docs/architecture.md: update parenthetical from ".claude/settings.json" to "hooks.json loaded via --settings" - docs/guides/dev/cli-internals.md: fix function name from buildClaudeCommand() to buildRunCommand() and add conditional --settings flag to the command diagram - internal/runtime/claude.go: rename temp file pattern from fullsend-settings-*.json to fullsend-hooks-*.json for consistency with the hooksConfig/GenerateHooksConfig rename Addresses review feedback on #6405

fullsend-ai-review · 2026-08-21T11:33:48Z

🤖 Finished Review · ✅ Success · Started 11:33 AM UTC · Completed 11:54 AM UTC

Commit: b07a630 · View workflow run →

maruiz93 · 2026-08-21T12:21:24Z

functional-tests failure: Pre-existing on main — not caused by this PR. Tracked in #6448 (ImportProfiles batch import races under parallel execution, same class as #6435).

fullsend-ai-coder Bot requested a review from a team as a code owner August 20, 2026 10:55

fullsend-ai-coder Bot added the ready-for-review Agent PR ready for human review label Aug 20, 2026

fullsend-ai-coder Bot assigned maruiz93 Aug 20, 2026

fullsend-ai-coder Bot temporarily deployed to dev August 20, 2026 10:55 Inactive

github-actions Bot deployed to site-preview August 20, 2026 10:56 View deployment

fullsend-ai-review Bot added the requires-manual-review Review requires human judgment label Aug 20, 2026

maruiz93 requested changes Aug 20, 2026

View reviewed changes

Comment thread internal/security/hooks.go Outdated

fullsend-ai-coder Bot temporarily deployed to dev August 20, 2026 12:05 Inactive

github-actions Bot deployed to site-preview August 20, 2026 12:07 View deployment

This comment was marked as outdated.

Sign in to view

fullsend-ai-review Bot added component/sandbox OpenShell sandbox environment component/runner Agent runner behavior and lifecycle labels Aug 20, 2026

fullsend-ai-coder Bot force-pushed the agent/6358-hooks-settings-path branch from 45ccde0 to 0a16c18 Compare August 20, 2026 13:59

fullsend-ai-coder Bot temporarily deployed to dev August 20, 2026 13:59 Inactive

fullsend-ai-coder Bot had a problem deploying to dev August 21, 2026 10:34 Failure

github-actions Bot deployed to site-preview August 21, 2026 10:35 View deployment

maruiz93 force-pushed the agent/6358-hooks-settings-path branch from f3153a0 to b924d2e Compare August 21, 2026 10:58

maruiz93 had a problem deploying to dev August 21, 2026 10:58 — with GitHub Actions Failure

maruiz93 approved these changes Aug 21, 2026

View reviewed changes

github-actions Bot deployed to site-preview August 21, 2026 11:00 View deployment

maruiz93 force-pushed the agent/6358-hooks-settings-path branch from b924d2e to c5ad996 Compare August 21, 2026 11:17

maruiz93 had a problem deploying to dev August 21, 2026 11:17 — with GitHub Actions Failure

github-actions Bot deployed to site-preview August 21, 2026 11:18 View deployment

fullsend-ai-coder Bot added 5 commits August 21, 2026 13:31

maruiz93 force-pushed the agent/6358-hooks-settings-path branch from c5ad996 to b07a630 Compare August 21, 2026 11:31

maruiz93 deployed to dev August 21, 2026 11:31 — with GitHub Actions Active

github-actions Bot deployed to site-preview August 21, 2026 11:32 View deployment

Uh oh!

Conversation

fullsend-ai-coder Bot commented Aug 20, 2026

Summary

Changes

Testing

Follow-up

Post-script verification

Uh oh!

github-actions Bot commented Aug 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Site preview

Uh oh!

fullsend-ai-review Bot commented Aug 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

codecov Bot commented Aug 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

fullsend-ai-review Bot commented Aug 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Review

Findings

Medium

Low

Review

Findings

Medium

Low

Review

Findings

Medium

Low

Review

Findings

Medium

Low

Review

Findings

Medium

Low

Review

Findings

Medium

Low

Review

Findings

Medium

Low

Uh oh!

Uh oh!

maruiz93 commented Aug 20, 2026

Uh oh!

maruiz93 commented Aug 20, 2026

Uh oh!

fullsend-ai-coder Bot commented Aug 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

fullsend-ai-coder Bot commented Aug 20, 2026

🔧 Fix agent — iteration 1 (human-triggered)

Tests: passed

Uh oh!

fullsend-ai-review Bot commented Aug 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

This comment was marked as outdated.

Uh oh!

maruiz93 commented Aug 20, 2026

Uh oh!

fullsend-ai-coder Bot commented Aug 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

fullsend-ai-coder Bot commented Aug 20, 2026

🔧 Fix agent — iteration 2 (human-triggered)

Uh oh!

fullsend-ai-review Bot commented Aug 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

fullsend-ai-review Bot commented Aug 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

github-actions Bot commented Aug 20, 2026 •

edited

Loading

fullsend-ai-review Bot commented Aug 20, 2026 •

edited

Loading

codecov Bot commented Aug 20, 2026 •

edited

Loading

fullsend-ai-review Bot commented Aug 20, 2026 •

edited

Loading

fullsend-ai-coder Bot commented Aug 20, 2026 •

edited

Loading

fullsend-ai-review Bot commented Aug 20, 2026 •

edited

Loading

fullsend-ai-coder Bot commented Aug 20, 2026 •

edited

Loading

fullsend-ai-review Bot commented Aug 20, 2026 •

edited

Loading

fullsend-ai-review Bot commented Aug 21, 2026 •

edited

Loading

fullsend-ai-review Bot commented Aug 21, 2026 •

edited

Loading

fullsend-ai-review Bot commented Aug 21, 2026 •

edited

Loading

fullsend-ai-review Bot commented Aug 21, 2026 •

edited

Loading