You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Every time you make a pull request, our system automatically looks through it. We check for security issues, mistakes in how you're setting up your infrastructure, and common code problems. We do this to make sure your changes are solid and won't cause any trouble later.
Talking to CodeAnt AI
Got a question or need a hand with something in your pull request? You can easily get in touch with CodeAnt AI right here. Just type the following in a comment on your pull request, and replace "Your question here" with whatever you want to ask:
@codeant-ai ask: Your question here
This lets you have a chat with CodeAnt AI about your pull request, making it easier to understand and improve your code.
Example
@codeant-ai ask: Can you suggest a safer alternative to storing this secret?
Preserve Org Learnings with CodeAnt
You can record team preferences so CodeAnt AI applies them in future reviews. Reply directly to the specific CodeAnt AI suggestion (in the same thread) and replace "Your feedback here" with your input:
@codeant-ai: Your feedback here
This helps CodeAnt AI learn and adapt to your team's coding style and standards.
Example
@codeant-ai: Do not flag unused imports.
Retrigger review
Ask CodeAnt AI to review the PR again, by typing:
@codeant-ai: review
Check Your Repository Health
To analyze the health of your code repository, visit our dashboard at https://app.codeant.ai. This tool helps you identify potential issues and areas for improvement in your codebase, ensuring your repository maintains high standards of code health.
@ThePlenkov, you've reached your PR review limit, so we couldn't start this review.
Next review available in:40 minutes
Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).
How can I continue?
After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.
To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.
How do review limits work?
CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.
For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.
Reviewing files that changed from the base of the PR and between 34f1f80 and 5908184.
⛔ Files ignored due to path filters (1)
bun.lock is excluded by !**/*.lock
📒 Files selected for processing (2)
package.json
packages/core/src/internal/plan.ts
📝 Walkthrough
Summary by CodeRabbit
New Features
Added host-process command execution with configurable command and environment allowlists.
Added timeout handling, output capture and truncation, artifact collection, workspace validation, and structured execution errors.
Added safeguards against root, sudo, and su execution.
Workspace, artifacts, environment, and credentials are now scoped per execution request.
Documentation
Added an implementation plan and updated host executor specifications, including scheduler-managed retries.
Chores
Updated package entry points and modernized lint commands.
Pinned development dependency versions.
Walkthrough
The pull request adds the HostExecutor runtime implementation, its public contracts, validation, process handling, artifact collection, and tests. It also moves execution paths to request scope, updates package entrypoints, removes deprecated ESLint options, and pins development dependencies.
Defines HostExecutorConfig, command allowlisting, typed errors, request-scoped paths and environment values, scheduler-owned retries, and privilege validation without setuid.
Host process execution and result handling packages/runtime-host/src/host-executor.ts, packages/runtime-host/src/__tests__/host-executor.test.ts, packages/runtime-host/src/__tests__/helpers/fixtures.ts
Public package surface and request-scoped behavior packages/runtime-host/src/index.ts, packages/runtime-host/package.json, packages/runtime-host/src/__tests__/public-api.test.ts, specs/05-runtime-host/spec.md
Exports the runtime-host API, updates ESM entrypoints and workspace dependencies, and documents request-scoped execution behavior.
➖ Requires filesystem access and can fail in edge cases (missing paths)
➖ More complexity; may be unnecessary if workspace is trusted/ephemeral in current threat model
Recommendation: The PR’s approach is solid for Wave 4: minimal dependencies, explicit security checks, and comprehensive tests. If this executor will be used in less-trusted workspaces, consider upgrading the cwd containment check to realpath-based validation and switching log truncation to byte-accurate accounting; otherwise the current implementation is a reasonable, reviewable baseline.
• Implements a deterministic allowlist that matches either absolute-path entries exactly or bare-name entries against the command basename; exposes readonly entries and rejects empty commands.
config.tsDefine HostExecutorConfig without per-run workspace/artifactDir fields+22/-0
Define HostExecutorConfig without per-run workspace/artifactDir fields
• Adds a strict config interface for enabling the executor, allowlist selection, bounded env forwarding/injection, maxLogBytes, and runAsUid validation expectations; documents that workspace/artifactDir arrive per ExecuteRequest.
errors.tsAdd runtime-host error classes with stable codes+31/-0
Add runtime-host error classes with stable codes
• Introduces HostExecutorError base class with code/context and two concrete subclasses: HostTimeoutError (HOST_TIMEOUT) and CommandNotAllowedError (COMMAND_NOT_ALLOWED).
• Implements the @sverka/runtime Executor interface for host processes with construction-time privilege escalation checks (runAsUid != 0; disallow sudo/su). Executes operations by validating type/timeout/allowlist, resolving a workspace-contained cwd, building a bounded env, spawning the child process with timeout (SIGTERM then SIGKILL after grace), truncating logs, and copying declared artifacts into request.artifactDir while reporting missing artifacts in the result error.
errors.test.tsAdd error hierarchy tests for runtime-host errors+54/-0
Add error hierarchy tests for runtime-host errors
• Validates HostExecutorError fields (name/code/context) and subclass behavior for HostTimeoutError and CommandNotAllowedError, including optional context.
fixtures.tsAdd test fixtures for PlanOperation, ExecuteRequest, and default config+60/-0
Add test fixtures for PlanOperation, ExecuteRequest, and default config
• Provides helpers to construct minimal host operations and requests plus a default HostExecutorConfig with a permissive allowlist and PATH forwarding for test runs.
spec.mdAmend Spec 05 to match built runtime contract (request-scoped env/credentials/paths)+21/-23
Amend Spec 05 to match built runtime contract (request-scoped env/credentials/paths)
• Updates the spec to clarify retry is scheduler-owned, and switches env/credentials and workspace/artifactDir references from operation/config fields to ExecuteRequest fields. Updates test plan commands to use bun run test via nx/vitest and adjusts environment/working-directory/artifact sections accordingly.
package.jsonAlign runtime-host dist outputs and add workspace deps+9/-5
Align runtime-host dist outputs and add workspace deps
• Updates main/module/types/exports to point at dist/index.mjs and dist/index.d.mts for ESM consistency. Adds @sverka/runtime and @sverka/ir as workspace dependencies.
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
This pull request is currently not up to standards. While the functional intent to implement the HostExecutor is correctly aligned with the architecture plan, the current implementation contains high-severity security flaws, including path traversal vulnerabilities in artifact collection and potential Denial-of-Service (DoS) via memory exhaustion in the logging mechanism.
Additionally, the execute method in host-executor.ts has become overly complex (cyclomatic complexity of 14), making it difficult to maintain and test. Codacy analysis reports 315 new issues and several code clones, indicating that significant cleanup and refactoring are required before this can be safely merged. The core executor logic is identified as high-risk and requires improved test coverage to validate boundary conditions and security constraints.
About this PR
The PR introduces 315 new static analysis issues and 8 code clones. A systemic cleanup is required to meet the project's quality standards. Additionally, the core host-executor.ts file is significantly more complex than recommended, which likely contributed to the high-severity logic errors found during review.
Test suggestions
HostExecutor.canExecute returns false when disabled or given a non-host operation type
HostExecutor.canExecute validates command against allowlist and ensures timeoutSeconds is positive
Process execution captures combined stdout/stderr and returns success status on exit code 0
Process execution returns failure status and correct exit code for non-zero exits
Timeouts trigger SIGTERM followed by SIGKILL after the 2s grace period
Environment variables from host are filtered through envAllowlist, while request env/credentials are fully forwarded
Operation working directory relative to workspace is honored but blocked if it attempts to escape via '..'
Constructor throws PRIVILEGE_ESCALATION if runAsUid is 0 or allowlist contains sudo/su
Declared artifacts are copied to artifactDir and missing files are reported in the result error
Logs are truncated and tagged with a notice when exceeding maxLogBytes
Increase unit test coverage for HostExecutor logic paths (currently identified as uncovered and complex)
Prompt proposal for missing tests
Consider implementing these tests if applicable:
1. Increase unit test coverage for HostExecutor logic paths (currently identified as uncovered and complex)
Timeout handling signals only the direct child PID, so descendants started by the command can
continue running after the operation fails. These leaked processes can keep consuming resources or
modifying the workspace during retries and later operations.
+ child.kill("SIGTERM");+ setTimeout(() => {+ if (!child.killed) {+ child.kill("SIGKILL");
Evidence
The process is spawned without process-group management and timeout calls kill() only on the
direct child. The implementation plan explicitly requires timeout cleanup not to leak the process.
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution
## Issue description
The timeout path terminates only the direct `ChildProcess`; helper and background processes spawned by it can survive. Timed-out host operations must clean up the complete process tree using platform-appropriate behavior.
## Issue Context
On Unix, create and terminate an isolated process group; provide an equivalent tree-termination strategy on Windows. Test a command that starts a long-lived descendant and verify no descendant remains after timeout.
## Fix Focus Areas
- packages/runtime-host/src/host-executor.ts[206-220]
- packages/runtime-host/src/__tests__/host-executor.test.ts[114-136]
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
2. Symlink bypasses workspace cwd 🐞 Bug⛨ Security
Description
resolveCwd checks only lexical path components, so an in-workspace symlink targeting an external
directory passes validation and becomes the child cwd. This violates the explicit
workspace-constrained working-directory guarantee.
The implementation never resolves filesystem symlinks before accepting cwd. The host-executor
contract explicitly requires cwd to remain within request.workspace.
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution
## Issue description
Lexical `resolve`/`relative` checks do not account for symlinks. Canonicalize both the workspace and requested existing working directory, then enforce containment using path-component boundaries before spawning.
## Issue Context
Define deliberate behavior for nonexistent working directories, and add a test where a symlink inside the workspace points outside it.
## Fix Focus Areas
- packages/runtime-host/src/host-executor.ts[148-164]
- packages/runtime-host/src/__tests__/host-executor.test.ts[194-232]
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
After sending SIGTERM, the grace-period callback only sends SIGKILL when !child.killed, but
Node.js sets child.killed to true as soon as the kill signal is successfully dispatched rather
than when the process actually exits. As a result, a child that ignores SIGTERM will never receive
SIGKILL and execute() can remain pending indefinitely despite the mandatory timeout.
The implementation calls child.kill('SIGTERM') and later (after the grace delay) decides whether
to send SIGKILL by checking child.killed. Node’s documentation for ChildProcess.killed indicates
it reflects whether a signal was successfully sent, not whether the process has terminated, so by
the time the grace timer fires the property will already be true from the earlier SIGTERM dispatch;
this makes the SIGKILL path effectively unreachable for processes that don’t exit on SIGTERM and
explains how the timeout safety mechanism can fail to complete.
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution
## Issue description
The timeout grace-period logic in `spawnProcess` incorrectly uses `child.killed` to decide whether to send SIGKILL after sending SIGTERM. In Node.js, `child.killed` becomes true once the signal is successfully dispatched (not when the process exits), so a SIGTERM-resistant child may never be force-killed and `execute()` may remain pending indefinitely.
## Issue Context
The timeout handling is intended to: send SIGTERM, wait `GRACE_PERIOD_MS`, then send SIGKILL if the process hasn’t exited (per the plan doc requirement of “SIGTERM, then SIGKILL after 2s grace”). To implement this correctly, process termination/closure must be tracked independently (e.g., via `close`/`exit` events) rather than using `child.killed`. Also ensure timers are managed safely: clear the grace timer if the process exits before it elapses, and clear both timeout timers during terminal event handling to avoid attempting to kill an already-exited process. Add a test that spawns a child which handles or ignores SIGTERM to verify SIGKILL is issued after the grace period when needed.
## Fix Focus Areas
- packages/runtime-host/src/host-executor.ts[212-220]
- packages/runtime-host/src/host-executor.ts[212-244]
- packages/runtime-host/src/host-executor.ts[243-273]
- packages/runtime-host/src/__tests__/host-executor.test.ts[114-136]
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
The data handlers accumulate all stdout and stderr until process close and apply maxLogBytes only
afterward. A noisy child can exhaust the runtime process's memory despite the configured log limit.
Both streams append without a size check for the process lifetime, and truncation occurs only in the
close handler. Thus maxLogBytes does not bound memory usage.
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution
## Issue description
Post-process truncation limits only the returned string, not memory consumed while the child runs. Enforce a combined byte budget in the stream handlers, retain only data within that budget, and record that excess output was discarded.
## Issue Context
The implementation must continue draining both pipes to avoid blocking the child while keeping retained data bounded. Add a test that emits substantially more than the configured limit.
## Fix Focus Areas
- packages/runtime-host/src/host-executor.ts[201-278]
- packages/runtime-host/src/__tests__/host-executor.test.ts[299-314]
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
collectArtifacts constructs artifact source paths from plan-controlled artifact.path (including
accepting absolute paths) and destination paths from artifact.name ?? artifact.path by simple
join operations without verifying containment within workspace/artifactDir, unlike
resolveCwd which explicitly rejects escaping paths. As a result, .. segments or absolute paths
can cause artifact collection to read from outside the workspace and write outside artifactDir,
potentially overwriting any file writable by the executor user.
ArtifactDeclaration path/name are plan-controlled strings with no format restriction
(packages/ir/src/plan.ts lines 90-94), and current validation does not impose additional artifact
path/name constraints. In collectArtifacts, the source path is derived by using artifact.path
directly when absolute or by joining it to workspace when relative, and the destination is derived
by joining artifactDir with artifact.name ?? artifact.path; because there is no
path.relative/..-prefix containment check (and parent directories are created before copying),
crafted values like ../... or absolute paths can escape these directories, in contrast to the
explicit WORKDIR_OUTSIDE_WORKSPACE guard in resolveCwd nearby.
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution
## Issue description
`collectArtifacts` resolves artifact source paths (`operation.artifacts[].path`) and destination paths (`artifact.name ?? artifact.path`) without enforcing that the resolved paths remain inside `workspace` and `artifactDir` respectively. This allows path traversal (`..`), absolute paths, and potentially symlink-based escapes to read files from outside the workspace and write/copy outside the configured artifact directory, including overwriting any file writable by the executor user.
## Issue Context
- The IR permits arbitrary strings for artifact `name` and `path`, and current plan validation does not constrain them.
- The same runtime-host file already implements a containment pattern for `operation.workingDir` in `resolveCwd` (using `path.relative` and rejecting `..`-prefixed results / outside-workspace paths), but `collectArtifacts` does not apply an equivalent check to artifact source/destination resolution.
- Destination handling creates parent directories before copying, which makes destination traversal especially risky.
- Add/extend tests to cover `../` traversal, absolute paths, and symlink-based destination escapes.
## Fix Focus Areas
- packages/runtime-host/src/host-executor.ts[281-304]
- packages/runtime-host/src/__tests__/host-executor.test.ts[268-297]
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
truncateLogs enforces maxLogBytes using logs.length/slice, which operate on UTF-16 code
units rather than bytes, so non-ASCII output can exceed the configured byte limit and truncation can
split multi-byte characters. It also appends TRUNCATION_NOTICE after slicing to maxLogBytes,
causing the returned logs to exceed maxLogBytes even for ASCII and violating the stated invariant
that output must never exceed the limit.
The configuration in config.ts defines maxLogBytes as a maximum log size in bytes, but
truncateLogs measures and truncates via String.prototype.length and slice, which count UTF-16
code units rather than UTF-8 bytes; this means strings containing multi-byte characters can remain
over the true byte budget and truncation may cut through a multi-byte character or surrogate pair.
Additionally, the runtime-host plan (engdocs/architecture/wave-04-runtime-host-plan.md §7) states
logs must “never exceed maxLogBytes,” yet the implementation slices to maxLogBytes and then
appends TRUNCATION_NOTICE, making the final output longer than the configured maximum by the
notice length.
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution
## Issue description
`truncateLogs` currently checks and truncates logs using JavaScript string code-unit length (`logs.length` / `slice`), even though `maxLogBytes` is defined as a byte limit. This can allow returned logs to exceed `maxLogBytes` (especially for non-ASCII text) and can also split multi-byte characters/surrogate pairs; additionally, the function appends `TRUNCATION_NOTICE` after slicing to the full limit, guaranteeing the final returned string exceeds `maxLogBytes` even for ASCII.
## Issue Context
- `maxLogBytes` is documented as a maximum log size **in bytes**.
- The architecture/implementation plan requires the final returned log output to **never exceed `maxLogBytes`**, including any truncation notice.
- Define sensible behavior when `maxLogBytes` is smaller than `TRUNCATION_NOTICE` (e.g., return a truncated notice-only string, return an empty string, or omit the notice), but ensure the invariant still holds.
## Fix Focus Areas
- packages/runtime-host/src/host-executor.ts[13-15]
- packages/runtime-host/src/host-executor.ts[276-279]
- packages/runtime-host/src/__tests__/host-executor.test.ts[299-314]
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
In the child's error event handler, logs is set solely to stderr: ${err.message}, discarding
any stdout/stderr output that was already buffered before the error fired, and mislabeling a
spawn-level error (e.g., ENOENT) as stderr content. This reduces diagnostic accuracy for partial
output that occurred before a spawn failure.
The 'close' handler correctly builds logs from the accumulated stdout/stderr buffers (`const rawLogs
= stdout + (stderr ? "\n" + stderr : "")`), but the 'error' handler ignores those same buffers
entirely and instead constructs logs from just the error message prefixed with the literal string
'stderr:', which is inconsistent and misleading since ChildProcess 'error' events are not stderr
stream data.
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution
## Issue description
The child process `error` event handler builds `logs` only from the error message (mislabeled with a `stderr:` prefix), discarding any stdout/stderr already captured before the failure.
## Issue Context
The `close` handler builds logs correctly by concatenating captured stdout and stderr; the `error` handler should follow the same pattern and additionally note the spawn error distinctly.
## Fix Focus Areas
- packages/runtime-host/src/host-executor.ts[229-241]
Build `logs` from the same `stdout`/`stderr` concatenation used in the close handler, and append the spawn error message as a separate line (not prefixed with `stderr:`) so partial output isn't lost and the error is clearly attributed.
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
Review mode: 🧠 Deep: This introduces security-sensitive process execution with allowlisting, credential/env handling, timeouts, artifacts, and substantial independent logic across implementation and tests, making multiple subtle defects plausible.
Tip of the day
💡 Did you know, you can group findings by type and pick your Finding display, from Minimal to Full
The shipped host executor still has concrete high-risk flaws, including allowlist bypasses for absolute paths, artifact path traversal, and broken SIGKILL escalation via child.killed; these remain blockers despite resolved discussions. CI also did not run for this non-trivial security-sensitive change.
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 12
🤖 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 `@engdocs/architecture/wave-04-runtime-host-plan.md`:
- Around line 163-165: Update the working-directory containment logic in the
runtime host plan to canonicalize both request.workspace and the resolved
operation.workingDir with realpath before checking containment. Reject relative
results equal to "..", beginning with ".." plus the platform separator, or
absolute paths; add tests covering sibling-prefix paths and symlink escapes.
In `@package.json`:
- Line 19: Update the workspace-local tsdown declaration in
packages/runtime-docker/package.json to match the root package.json pin of
0.22.14, or ensure the lockfile enforces that single version across the
workspace. Preserve the existing build dependency configuration while preventing
the caret range from resolving a different version.
In `@packages/core/package.json`:
- Line 18: Update the lint command in the Nx target of project.json to match the
package.json lint script and remove the obsolete --ext .ts argument, while
preserving the existing eslint src invocation.
In `@packages/runtime-host/src/__tests__/host-executor.test.ts`:
- Around line 299-313: The HostExecutor output handling must enforce maxLogBytes
during collection, not after accumulating complete stdout and stderr. Update the
execute/log collection flow and truncateLogs logic to use a bounded buffer that
continues draining both streams, reserves space for the "[log truncated]"
notice, and never exceeds maxLogBytes; tighten the test assertion to require
result.logs.length to be at most maxLogBytes.
- Around line 115-127: Update HostExecutor timeout handling and spawnProcess
termination to track actual child process closure rather than relying on
child.killed, clear the SIGKILL grace timer when the process closes, and
escalate to SIGKILL for the process group or entire process tree when SIGTERM is
ignored. Ensure descendants are terminated so captured stdio closes, and add
coverage for both a SIGTERM-ignoring child and a persistent descendant.
In `@packages/runtime-host/src/allowlist.ts`:
- Around line 27-35: Update Allowlist.isAllowed so non-absolute entries match
only commands that are themselves bare names, never an absolute command path;
retain exact matching for absolute allowlist entries. Adjust the corresponding
allowlist test covering bare entries and absolute commands to verify
/workspace/tools/node is rejected when only "node" is allowed.
In `@packages/runtime-host/src/host-executor.ts`:
- Around line 55-56: Update the timeout validation around
operation.timeoutSeconds to reject non-finite values and values whose
millisecond conversion exceeds Node’s supported timer range before calling
spawnProcess. Preserve the existing rejection for undefined and non-positive
values, returning the same MISSING_TIMEOUT behavior for every unsupported
timeout.
- Around line 147-148: Update the path validation around relative() in the host
executor to use path-segment boundaries: reject only rel === "..", rel beginning
with ".." followed by the platform separator, or an absolute rel. Preserve valid
child paths such as "..cache" and use the existing separator/path utilities.
- Around line 204-211: Update the timeout logic around the child process so the
grace-period callback checks whether the child’s close event has fired, rather
than relying on child.killed. Track the close state from the child process close
handler and send SIGKILL after GRACE_PERIOD_MS when it remains open, preserving
the existing SIGTERM-then-grace-period escalation in the executor flow.
- Around line 27-47: The HostExecutor constructor currently validates runAsUid
but does not apply it to child processes. Update the child-process spawn call to
pass config.runAsUid through the uid option, and reject configurations with an
unset runAsUid when the executor is running as root. Add tests covering the
spawned UID and this fail-closed validation path.
- Around line 158-181: Restrict request.env in buildEnv before merging it into
the child environment by applying a dedicated request-environment allowlist.
Reject PATH, NODE_OPTIONS, and dynamic-loader variables such as LD_PRELOAD, and
reject any keys colliding with config.env or request.credentials so protected
values cannot be overwritten. Preserve the existing merge behavior only for
validated request environment entries.
In `@specs/05-runtime-host/spec.md`:
- Around line 313-315: Update the fenced command block under Commands in
specs/05-runtime-host/spec.md with blank lines immediately before and after the
fence. In host-executor.ts, update resolveCwd to realpath the workspace and
candidate, reject escaped relative paths including "..", parent-prefixed paths,
and absolute paths; resolve bare commands before buildEnv merges request.env.
Pass validated runAsUid to spawn with platform-specific validation and tests,
track actual child exit instead of child.killed before SIGKILL, bound
stdout/stderr capture before truncateLogs, and constrain artifact source and
destination paths to their request-scoped roots.
🪄 Autofix
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: Organization UI
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: 64b586cc-2410-4156-b69c-fc3cc44420fd
📥 Commits
Reviewing files that changed from the base of the PR and between 3629bde and 34f1f80.
[warning] Importing child_process exposes a command-execution surface; ensure any command/argument built from input is validated, and prefer execFile/spawn with an argument array over exec.
Context: import { spawn } from "node:child_process";
Note: [CWE-78] Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection').
[grammar] ~40-~40: Ensure spelling is correct
Context: ...ostExecutorError→HostTimeoutError, CommandNotAllowedError. - Public re-exports from src/index.ts...
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
[grammar] ~171-~171: Ensure spelling is correct
Context: ...alidate in constructor; do not actually setuid. ### Slice I — Artifacts + log truncation 18....
Line 21 pins typescript-eslint to 8.66.0, but the previous range was ^8.67.0. Confirm that this downgrade is intentional, that the lockfile resolves 8.66.0, and that it works with ESLint 9.39.5 and TypeScript 5.9.3.
packages/checks/package.json (1)
18-18: LGTM!
packages/cli/package.json (1)
18-18: LGTM!
packages/compiler-earthly/package.json (1)
18-18: LGTM!
packages/runtime-docker/package.json (2)
5-14: LGTM!
Also applies to: 18-18
21-24: 🗄️ Data Integrity & Integration
Verify the workspace:* dependency rewrite before publishing.
Lines 22-23 add workspace:* dependencies to a package with public exports. Confirm that the pack/publish workflow rewrites them to concrete versions in the packed manifest. Otherwise, consumers outside the workspace may fail to install the package.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
![codacy-production[bot]](https://avatars.githubusercontent.com/in/56611?s=60&v=4){kind=small}
![qodo-code-review[bot]](https://avatars.githubusercontent.com/in/484649?s=60&v=4){kind=small}
codeant-ai
Bot
added
the
size:XXL
![codeant-ai[bot]](https://avatars.githubusercontent.com/in/646884?s=60&v=4){kind=small}
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
User description
Summary
Test plan
Stacked on #3
Generated with Devin
CodeAnt-AI Description
Add a controlled host executor for running approved local commands
What Changed
Impact
✅ Controlled local command execution✅ Fewer stuck processes and oversized logs✅ Reduced environment leakage and workspace escapes🔄 Retrigger CodeAnt AI Review
💡 Usage Guide
Checking Your Pull Request
Every time you make a pull request, our system automatically looks through it. We check for security issues, mistakes in how you're setting up your infrastructure, and common code problems. We do this to make sure your changes are solid and won't cause any trouble later.
Talking to CodeAnt AI
Got a question or need a hand with something in your pull request? You can easily get in touch with CodeAnt AI right here. Just type the following in a comment on your pull request, and replace "Your question here" with whatever you want to ask:
This lets you have a chat with CodeAnt AI about your pull request, making it easier to understand and improve your code.
Example
Preserve Org Learnings with CodeAnt
You can record team preferences so CodeAnt AI applies them in future reviews. Reply directly to the specific CodeAnt AI suggestion (in the same thread) and replace "Your feedback here" with your input:
This helps CodeAnt AI learn and adapt to your team's coding style and standards.
Example
Retrigger review
Ask CodeAnt AI to review the PR again, by typing:
Check Your Repository Health
To analyze the health of your code repository, visit our dashboard at https://app.codeant.ai. This tool helps you identify potential issues and areas for improvement in your codebase, ensuring your repository maintains high standards of code health.