fix(ci): switch Workers Builds from npm to pnpm (closes #111)

[chitcommit]

Summary

• Workers Builds was running npm clean-install but the repo uses pnpm (pnpm-lock.yaml committed, package-lock.json gitignored). A stale cached npm lockfile referenced @tailwindcss/vite@^4.1.3 (removed from the project) and conflicted with vite@^7, failing every recent build.
• Add "packageManager": "pnpm@10.32.1" so Workers Builds picks pnpm.
• Switch build command to pnpm install --frozen-lockfile && pnpm exec vite build in both wrangler.jsonc and deploy/system-wrangler.jsonc.

Closes #111.

Test plan

• pnpm install --frozen-lockfile clean
• pnpm exec vite build --outDir dist/public succeeds
• Watch first Workers Build on this PR — should now run pnpm and succeed

🤖 Generated with Claude Code

Summary by CodeRabbit

• Chores
  • Standardized builds to use pnpm with a frozen lockfile, producing public/dist assets for production.
  • Declared pnpm@10.32.1 as the project package manager.
  • CI workflow step updated to rely on the action’s default pnpm setup (no explicit version specified).

[github-actions]

@coderabbitai review

Please evaluate:

• Security implications
• Credential exposure risk
• Dependency supply chain concerns
• Breaking API changes

[claude]

Code Review — PR #115: fix(ci): switch Workers Builds from npm to pnpm

Summary: Small, focused build-config fix. Root cause is clear, changes are minimal and correct. Approved with a few minor notes below.

---

Overview

The PR correctly identifies that Cloudflare Workers Builds was invoking npm (via npx) while the repo is committed to pnpm (pnpm-lock.yaml is tracked, package-lock.json is gitignored). The stale npm lockfile pulling in a removed package (@tailwindcss/vite@^4.1.3) against vite@^7 was causing build failures. The fix is the right level of invasiveness — no unnecessary refactoring.

---

What Looks Good ✅

• --frozen-lockfile is correct for CI — fails loudly if the lockfile is stale rather than silently mutating it. Right call.
• Both wrangler configs updated consistently — wrangler.jsonc and deploy/system-wrangler.jsonc stay in sync.
• packageManager field — corepack-compatible declaration; lets any tooling that respects the field (including some Cloudflare environments) auto-select pnpm.
• Minimal diff — 3 additions, 2 deletions. No scope creep.

---

Minor Issues / Suggestions

1. packageManager field is missing the integrity hash (low severity)

// current
"packageManager": "pnpm@10.32.1"

// corepack best-practice (prevents MITM on pnpm download)
"packageManager": "pnpm@10.32.1+sha512.<hash>"

Run corepack use pnpm@10.32.1 locally — it writes both the version and hash. Not blocking, but worth doing for supply-chain hygiene.

2. Build command runs pnpm install on every Workers Build

This is intentional and correct given the platform constraint (Workers Builds was using npm), but it does add install time to every build. If Cloudflare ever adds native pnpm support or if you can configure the package manager at the project level in the Workers Builds UI, this explicit install step can be removed. Worth a comment in the wrangler config or a follow-up ticket so it doesn't get forgotten.

3. Consider pnpm run build instead of pnpm exec vite build

// current
"command": "pnpm install --frozen-lockfile && pnpm exec vite build --outDir dist/public"

// alternative — delegates to the npm script
"command": "pnpm install --frozen-lockfile && pnpm run build"

The build script in package.json also runs esbuild for the server bundle alongside vite build. pnpm exec vite build only builds the frontend. If Workers Builds needs the server bundle too, pnpm run build is safer. If frontend-only is intentional here (Workers uses the asset pipeline, not the Node bundle), this is fine as-is — just worth confirming.

---

Security

No concerns. Changing from npx vite to pnpm exec vite is neutral to slightly better (uses the locally resolved binary rather than npx's resolution path).

---

Test Plan

The unchecked item ("Watch first Workers Build on this PR") is the critical validation. Everything else looks correct statically. Recommend merging after confirming the first Workers Build on this branch goes green.

---

Verdict: Approve with suggestions — the fix is correct and the suggestions above are non-blocking improvements. Ship it once the live Workers Build passes.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: e6b4e8cb67

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Remove CI package install from Wrangler custom build

This change puts pnpm install --frozen-lockfile into build.command, but Cloudflare Workers Builds explicitly does not honor Wrangler build custom-build settings, so this does not reliably fix the Workers Builds npm/pnpm mismatch it targets. At the same time, Wrangler custom builds run during local wrangler dev/wrangler deploy, so this introduces a repeated networked install step for every local deploy/dev path, increasing failure risk and build latency without affecting the CI path you intended to fix.

Useful? React with 👍 / 👎.

[Copilot]

Pull request overview

This PR updates Cloudflare Workers Builds to use pnpm (matching the repo’s committed pnpm-lock.yaml) to avoid npm lockfile/cache conflicts that were breaking builds.

Changes:

• Add packageManager: "pnpm@10.32.1" to package.json so build environments select pnpm.
• Update Workers build.command in both wrangler configs to run pnpm install --frozen-lockfile followed by pnpm exec vite build.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File	Description
wrangler.jsonc	Switch Workers build command from npx vite build to pnpm-based install + build.
package.json	Pin the repository package manager to pnpm.
deploy/system-wrangler.jsonc	Mirror the pnpm-based build command change for the deploy config.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 218aa17d-df6b-4c8d-89e0-88364ba245eb

📥 Commits

Reviewing files that changed from the base of the PR and between d90de07 and 6fda741.

📒 Files selected for processing (1)

• deploy/system-wrangler.jsonc

🚧 Files skipped from review as they are similar to previous changes (1)

• deploy/system-wrangler.jsonc

---

📝 Walkthrough

Walkthrough

Adds a repository packageManager field for pnpm, updates Cloudflare Workers build commands to install with pnpm --frozen-lockfile and run Vite via pnpm exec, and removes the explicit pnpm version from the GitHub Actions pnpm setup step.

Changes

pnpm Standardization

Layer / File(s)	Summary
Package Manager Declaration package.json	Added packageManager field declaring pnpm@10.32.1.
Build Command Updates wrangler.jsonc, deploy/system-wrangler.jsonc	Replaced npx vite build with pnpm install --frozen-lockfile && pnpm exec vite build --outDir dist/public.
CI pnpm Setup .github/workflows/security-gates.yml	Removed explicit with.version: 10 from pnpm/action-setup@v4 step so the action uses its default pnpm version.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Poem

🐰 A hop to pnpm, locks held tight,

installs hum and builds take flight,
npx retires, the scripts align,
CI trusts defaults, no version line,
carrots for consistency tonight.

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 inconclusive)

Check name	Status	Explanation	Resolution
Linked Issues check	❓ Inconclusive	The PR addresses the core requirement from #111 by configuring the repository to use pnpm for Workers Builds via the packageManager field and updated build commands, though the underlying local file dependency blocker remains unresolved.	The local '@chittyos/schema' file dependency must be resolved (via registry, git, or monorepo context) before Workers Builds can succeed in CI, despite the pnpm configuration fix being correct.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and specifically identifies the main change: switching Workers Builds from npm to pnpm, with a reference to the linked issue #111.
Out of Scope Changes check	✅ Passed	All changes are directly related to switching the build system from npm to pnpm: updates to package.json, wrangler.jsonc, deploy/system-wrangler.jsonc, and removing explicit version pinning from the pnpm setup action.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/workers-builds-use-pnpm

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

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 `@deploy/system-wrangler.jsonc`:
- Around line 54-56: The build step's command in the "build" object runs inside
deploy/ so pnpm install fails because package.json is at the repo root; add a
"cwd" property to the same "build" object (alongside "command") and set it to
the repository root (e.g., "..") so the pnpm install and Vite build run from the
correct directory; update the "build" object (the "command" and new "cwd"
properties) accordingly.

🪄 Autofix (Beta)

✅ Autofix completed

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 62944f89-26bc-4640-bdbf-74b2ae148197

📥 Commits

Reviewing files that changed from the base of the PR and between 2739779 and e6b4e8c.

📒 Files selected for processing (3)

• deploy/system-wrangler.jsonc
• package.json
• wrangler.jsonc

[github-actions]

@coderabbitai review

Please evaluate:

• Security implications
• Credential exposure risk
• Dependency supply chain concerns
• Breaking API changes

[claude]

Code Review — PR #115: fix(ci): switch Workers Builds from npm to pnpm

Verdict: ✅ Approve with minor suggestions — root cause is correctly diagnosed, diff is minimal and precise.

---

Overview

Workers Builds was invoking npx vite (npm) while the repo is committed to pnpm (pnpm-lock.yaml tracked, package-lock.json gitignored). A stale cached npm lockfile referenced @tailwindcss/vite@^4.1.3 (already removed) conflicting with vite@^7, breaking every build. The fix is exactly as invasive as it needs to be.

---

What Looks Good ✅

• --frozen-lockfile is the right call for CI — fails loudly on lockfile drift rather than silently mutating dependencies.
• packageManager field in package.json — Corepack-compatible; lets Workers Builds, pnpm/action-setup, and other tooling auto-detect pnpm without repetition.
• security-gates.yml cleanup — removing the hardcoded version: 10 from pnpm/action-setup@v4 is correct. The action reads packageManager from package.json when no version is specified, so this keeps the pinned version in one place (DRY).
• Both wrangler configs updated — wrangler.jsonc and deploy/system-wrangler.jsonc stay in sync.

---

Suggestions (non-blocking)

1. packageManager is missing the Corepack integrity hash

// current — version only
"packageManager": "pnpm@10.32.1"

// corepack best-practice — version + SHA hash
"packageManager": "pnpm@10.32.1+sha512.<hash>"

Run corepack use pnpm@10.32.1 locally and it writes both. The hash prevents MITM on the pnpm binary download. Low severity, but it's a one-time improvement worth making.

2. Build command rebuilds node_modules on every Workers Build

"command": "pnpm install --frozen-lockfile && pnpm exec vite build --outDir dist/public"

This is intentional (Workers Builds doesn't natively detect pnpm without packageManager being honoured), but it adds cold-install time to every deployment. If Cloudflare starts honouring the packageManager field at the project level, the explicit install step can be removed. Suggest a follow-up ticket to revisit once this PR confirms the fix works.

3. pnpm exec vite build vs pnpm run build

The build script in package.json runs both vite build (frontend) and esbuild (server bundle):

"build": "vite build && esbuild server/dev.ts --platform=node --packages=external --bundle --format=esm --outdir=dist"

The current build command only runs vite build (frontend only). If Workers Builds relies solely on the asset pipeline this is intentional, but if the server bundle is also needed, pnpm run build would be safer. Worth confirming this is deliberate.

---

Security

No concerns. Switching from npx vite to pnpm exec vite is neutral-to-slightly-better (resolves from the local binary rather than npx's resolution path, reducing the surface for dependency confusion).

---

Test Plan

The unchecked item — "Watch first Workers Build on this PR" — is the critical validation. Merge once the live Workers Build on this branch goes green.

[coderabbitai]

🧩 Analysis chain

@github-actions[bot]: Here is the security evaluation for PR #115.

---

Security Review: Switch Workers Builds from npm to pnpm

1. 🔒 Security Implications

Overall: Low risk — the changes are confined to build toolchain configuration.

The PR modifies only three files: package.json (adds packageManager field), wrangler.jsonc, and deploy/system-wrangler.jsonc (updated build commands). No application logic, authentication paths, or runtime behaviour is altered.

The packageManager field leverages Corepack to enforce the declared package manager. However, note that the field does not include a content hash (e.g., pnpm@10.32.1+sha256.<hash>), which Corepack supports for stricter pinning. Without the hash, the version is pinned by version string only — acceptable for most CI contexts, but consider adding the integrity hash for hardened supply chain environments.

---

2. 🔑 Credential Exposure Risk

No credential exposure detected.

• The build commands (pnpm install --frozen-lockfile && pnpm exec vite build) contain no embedded tokens, API keys, or secrets.
• The wrangler configuration files appear to reference bindings/routes without inline credentials (secrets should be configured in the CF dashboard as environment variables, not in wrangler.jsonc).
• No .npmrc with auth tokens scoped to private registries is introduced by this PR.

---

3. 📦 Dependency Supply Chain Concerns

--frozen-lockfile is a strong positive. Using pnpm install --frozen-lockfile ensures the committed pnpm-lock.yaml is respected exactly, preventing unexpected dependency resolution during CI builds.

pnpm version audit for 10.32.1:

CVE	Affected versions	Fixed in	Status for 10.32.1
CVE-2025-69262 (Command Injection via .npmrc tokenHelper)	6.25.0 through 10.26.2	10.27.0	✅ Patched
CVE-2025-69263 (HTTP tarball deps without integrity hashes)	10.26.2 and below	10.26.0	✅ Patched
CVE-2026-23890/23889 (path traversal in bin linking/tarball extraction)	prior to 10.28.1	10.28.1	✅ Patched

pnpm@10.32.1 is above all known patched version thresholds. The latest published version is 10.33.2. Upgrading to 10.33.2 in the packageManager field (and regenerating the lockfile if needed) would keep the toolchain at the most current release, but 10.32.1 carries no known unpatched vulnerabilities.

Minor recommendation: Consider upgrading "packageManager": "pnpm@10.33.2" to stay current, and optionally add the Corepack integrity hash for the strongest pin.

---

4. 🔄 Breaking API Changes

None detected.

• The build output target (dist/public) is consistent with what was previously used via npx vite build --outDir dist/public.
• pnpm exec vite build is a direct replacement for npx vite build — functionally equivalent in this context.
• No changes to wrangler.jsonc bindings, routes, triggers, environments, or assets configuration outside the build.command field.
• The packageManager field addition to package.json is purely additive and backwards-compatible.

---

Summary

Category	Finding	Severity
Security implications	Build-toolchain only, no runtime changes	✅ Low
Credential exposure	No credentials embedded in changed files	✅ None
Supply chain	--frozen-lockfile enforced; pnpm 10.32.1 has no unpatched known CVEs	✅ Low (upgrade to 10.33.2 suggested)
Breaking API changes	No breaking changes; pnpm exec vite build is equivalent to npx vite build	✅ None

The PR is safe to merge. The only actionable suggestion is upgrading to the latest pnpm patch (10.33.2) for completeness.

---

🏁 Script executed:

#!/bin/bash
# Read the relevant changed files
echo "=== package.json ==="
cat package.json

echo ""
echo "=== wrangler.jsonc ==="
cat wrangler.jsonc

echo ""
echo "=== deploy/system-wrangler.jsonc ==="
cat deploy/system-wrangler.jsonc

echo ""
echo "=== Check for any hardcoded secrets or tokens in wrangler files ==="
rg -n "(token|secret|key|password|credential|API_KEY|AUTH)" wrangler.jsonc deploy/system-wrangler.jsonc --ignore-case || echo "None found"

echo ""
echo "=== Check pnpm-lock.yaml exists ==="
fd "pnpm-lock.yaml" --max-depth 2

echo ""
echo "=== Check .npmrc or .pnpmrc for credential concerns ==="
fd "\.npmrc|\.pnpmrc" --max-depth 2 | xargs cat 2>/dev/null || echo "No .npmrc/.pnpmrc found"

echo ""
echo "=== Check package.json packageManager field and scripts ==="
python3 -c "import json; d=json.load(open('package.json')); print('packageManager:', d.get('packageManager')); print('scripts:', json.dumps(d.get('scripts',{}), indent=2))"

Length of output: 17495

---

@github-actions[bot]: Here is the updated security evaluation, now based on direct inspection of all changed and related files.

---

Security Review: PR #115 — Switch Workers Builds from npm to pnpm

1. 🔒 Security Implications

Overall: Low risk for the PR changes themselves; one pre-existing concern worth flagging.

The PR modifies only three files (package.json, wrangler.jsonc, deploy/system-wrangler.jsonc) and all changes are confined to build toolchain configuration. No application logic, authentication paths, or runtime behaviour is altered.

⚠️ Pre-existing: account_id hardcoded in wrangler files
Both wrangler files contain "account_id": "0bc21e3a5a9de1a4cc843be9c3e98121" in plain text in a (presumably public) repository. Cloudflare account IDs are not secrets in the cryptographic sense, but their public exposure narrows the attack surface for targeted phishing or social engineering. This was not introduced by this PR, but is worth tracking. Cloudflare's recommendation is to avoid committing account_id and instead use CLOUDFLARE_ACCOUNT_ID as an environment variable.

---

2. 🔑 Credential Exposure Risk

No credential exposure in the PR changes. Verified from file inspection:

• Build commands (pnpm install --frozen-lockfile && pnpm exec vite build --outDir dist/public) contain no embedded tokens or secrets.
• The wrangler files document required secrets (e.g., DATABASE_URL, JWT_SECRET, CHITTY_AUTH_SERVICE_TOKEN) only in comments as instructions to use wrangler secret put — actual values are absent. ✅
• No .npmrc or .pnpmrc files exist in the repo, so no registry auth tokens are present. ✅
• All production secrets are correctly managed externally via the Cloudflare dashboard/CLI.

---

3. 📦 Dependency Supply Chain Concerns

pnpm 10.32.1 CVE Status

CVE	Description	Fixed in	10.32.1 status
CVE-2025-69264 (RCE via git-hosted deps executing lifecycle scripts during pnpm install; affects 10.0.0–10.25.x)	RCE	10.26.0	✅ Patched
CVE-2025-69263 (HTTP/git tarball deps stored without integrity hashes, allowing different code to be served on each install)	Supply chain	10.26.0	✅ Patched
CVE-2026-23890 (path traversal in bin linking via @-prefixed package names, allowing shims/symlinks outside node_modules/.bin)	Path traversal	10.28.1	✅ Patched
CVE-2026-23889 (path traversal in tarball extraction, files written outside package directory on Windows)	Path traversal	10.28.1	✅ Patched

pnpm@10.32.1 has no known unpatched CVEs. ✅

--frozen-lockfile is a strong positive

The committed pnpm-lock.yaml will be used as-is, preventing unexpected dependency resolution drift in CI. ✅

pnpm overrides block (positive signal)

package.json already contains security-conscious version overrides for express-rate-limit, @hono/node-server, axios, and rollup — indicating active supply chain hygiene. ✅

onlyBuiltDependencies allowlist is maintained

The pnpm.onlyBuiltDependencies field explicitly lists only better-sqlite3, bufferutil, es5-ext, and esbuild as allowed to run lifecycle scripts. This limits the blast radius of a compromised package. ✅

⚠️ file: dependency will likely break the Workers Build

package.json contains:

"@chittyos/schema": "file:../../CHITTYFOUNDATION/chittyschema"

This is a local path dependency pointing two directories above the repo root. When Cloudflare Workers Builds clones this repository into an isolated build environment, that path (../../CHITTYFOUNDATION/chittyschema) will not exist, causing pnpm install --frozen-lockfile to fail immediately. This is a pre-existing issue not introduced by this PR, but it may be the real reason the 0-second build failures described in issue #111 persist even after this fix. This should be the highest-priority follow-up item.

pnpm 11 supply chain improvements not yet available at 10.x

pnpm 11 introduced a default minimum release age of 24 hours, meaning newly published package versions are not eligible for installation until they have existed for at least one day. pnpm 11 also enables blockExoticSubdeps by default, preventing dependencies from being resolved through non-standard sources such as Git repositories or direct tarball URLs. These defaults are not present in 10.x — a longer-term consideration if upgrading.

---

4. 🔄 Breaking API Changes

None. pnpm exec vite build is a direct functional equivalent of npx vite build. The --outDir dist/public output directory is consistent with the assets.directory in both wrangler config files. No bindings, routes, triggers, environments, or wrangler configuration blocks outside build.command were modified.

---

Summary

Category	Finding	Severity
Security implications	Build-toolchain only; account_id pre-existing exposure	⚠️ Low (pre-existing)
Credential exposure	No secrets in changed files	✅ None
Supply chain – pnpm CVEs	All known CVEs patched at 10.32.1	✅ Low
Supply chain – file: dependency	@chittyos/schema: file:../../... will fail in CF Workers Build CI	🔴 High (pre-existing, blocks fix)
Breaking API changes	None	✅ None

Recommendation: The PR itself is clean and correct, but the file: local dependency is very likely why CI builds fail in 0 seconds. That should be resolved — either by publishing @chittyos/schema to a registry, using a git dependency, or configuring the Workers Build environment to have access to the monorepo root — before expecting this fix to succeed on CI.

✅ Actions performed

Review triggered.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

[chitcommit]

CI status update after d90de07:

• ✅ pnpm version conflict resolved (workflow's version: 10 removed; packageManager is now sole source of truth)
• ❌ Dependency Audit now fails on a different, pre-existing error: `pnpm install --frozen-lockfile` rejects `@chittyos/schema: file:../../CHITTYFOUNDATION/chittyschema` (local path dep not in lockfile, and won't resolve in CI checkout regardless)
• ❌ PR Governance Check — pre-existing `Missing CODEOWNERS`, unrelated to this PR

The file: dep is the same root issue the in-flight chittyos-schema-public-npm-migration plan is meant to address. This PR does what it set out to do (switch Workers Builds from npm→pnpm); the residual failures are independent and were already failing on main.

Recommend merging once the @chittyos/schema migration lands, or merging now if those two checks are accepted as not-required.

[coderabbitai]

Note

Autofix is a beta feature. Expect some limitations and changes as we gather feedback and continue to improve it.

Fixes Applied Successfully

Fixed 1 file(s) based on 1 unresolved review comment.

Files modified:

• deploy/system-wrangler.jsonc

Commit: 6fda741e5867c44c47ed55056c69730cb4965f88

The changes have been pushed to the fix/workers-builds-use-pnpm branch.

Time taken: 1m 37s

[github-actions]

@coderabbitai review

Please evaluate:

• Security implications
• Credential exposure risk
• Dependency supply chain concerns
• Breaking API changes

[coderabbitai]

@github-actions[bot]: Here is the security evaluation for PR #115.

---

Security Review: Switch Workers Builds from npm to pnpm

1. 🔒 Security Implications

Overall: Low risk — the changes are confined to build toolchain configuration.

The PR modifies only three files: package.json (adds packageManager field), wrangler.jsonc, and deploy/system-wrangler.jsonc (updated build commands). No application logic, authentication paths, or runtime behaviour is altered.

The packageManager field leverages Corepack to enforce the declared package manager. However, note that the field does not include a content hash (e.g., pnpm@10.32.1+sha256.<hash>), which Corepack supports for stricter pinning. Without the hash, the version is pinned by version string only — acceptable for most CI contexts, but consider adding the integrity hash for hardened supply chain environments.

---

2. 🔑 Credential Exposure Risk

No credential exposure in the PR changes.

The build commands (pnpm install --frozen-lockfile && pnpm exec vite build --outDir dist/public) contain no embedded tokens or secrets. As noted in the prior review, required secrets (e.g., DATABASE_URL, JWT_SECRET) appear only in comments as instructions to use wrangler secret put — actual values are absent. ✅

⚠️ Pre-existing (not introduced by this PR): Both wrangler files contain "account_id" hardcoded in plain text. Cloudflare's recommendation is to use CLOUDFLARE_ACCOUNT_ID as an environment variable instead. This is worth a follow-up issue.

---

3. 📦 Dependency Supply Chain Concerns

pnpm 10.32.1 CVE Status

CVE / Advisory	Description	Fixed in	10.32.1 status
CVE-2025-69263	HTTP tarball dependencies stored without integrity hashes, allowing remote server to serve different content on each install — attackers can serve different code to different users or CI/CD environments	10.26.0	✅ Patched
CVE-2026-23890	Path traversal in pnpm's bin linking — malicious npm packages can create executable shims or symlinks outside node_modules/.bin via @-prefixed package names, leaving path traversal sequences intact after normalization	10.28.1	✅ Patched
CVE-2026-23889	Path traversal in pnpm's tarball extraction, allowing malicious packages to write files outside the package directory on Windows	10.28.1	✅ Patched

pnpm@10.32.1 has no known unpatched CVEs. ✅

Current version landscape

The latest published pnpm version is 11.0.8. pnpm 9 reached EOL on Apr 30, 2026 and is no longer receiving security updates; pnpm 11.0.6 (and newer) and pnpm 10 are the two currently supported release lines.

Note on pnpm 11: pnpm 11 tightens security defaults introduced throughout the v10 cycle and requires Node.js 22 or newer — pnpm itself is now pure ESM. Upgrading would be a non-trivial migration; staying on pnpm 10.x is fully supported for now.

pnpm 11 security defaults not yet available in 10.x

pnpm 11 introduces three hardened defaults: a Minimum Release Age of 1,440 minutes (24 hours), blocking of exotic subdependencies by default, and a new Allow Builds model for controlling which packages can execute build scripts during installation — the default posture now favors security over immediacy. These protections are opt-in on 10.x.

--frozen-lockfile is a strong positive ✅

Using pnpm install --frozen-lockfile ensures the committed pnpm-lock.yaml is respected exactly, preventing unexpected dependency resolution drift in CI.

⚠️ file: dependency will break Workers Builds (pre-existing, blocks this fix)

package.json contains a file:../../CHITTYFOUNDATION/chittyschema local path dependency for @chittyos/schema. When Cloudflare Workers Builds clones the repository into an isolated build environment, that relative path will not exist and pnpm install --frozen-lockfile will fail immediately. As @chitcommit noted above, the chittyos-schema-public-npm-migration plan is the appropriate resolution.

onlyBuiltDependencies allowlist (positive signal ✅)

package.json restricts lifecycle scripts to an explicit allowlist (better-sqlite3, bufferutil, es5-ext, esbuild), limiting the blast radius of a compromised package.

---

4. 🔄 Breaking API Changes

None. pnpm exec vite build is a direct functional equivalent of npx vite build. The --outDir dist/public output directory is consistent with the assets.directory in both wrangler config files. No bindings, routes, triggers, environments, or wrangler configuration blocks outside build.command were modified. The packageManager field addition to package.json is purely additive and backwards-compatible.

---

Summary

Category	Finding	Severity
Security implications	Build-toolchain only; account_id pre-existing exposure	⚠️ Low (pre-existing)
Credential exposure	No secrets in changed files	✅ None
Supply chain – pnpm CVEs	All known CVEs patched at 10.32.1	✅ Low
Supply chain – file: dependency	@chittyos/schema: file:../../... will fail in CF Workers Build CI	🔴 High (pre-existing, blocks fix)
Breaking API changes	None	✅ None

The PR changes themselves are clean. The file: local dependency is very likely why CI builds fail in 0 seconds, and that should be resolved via the @chittyos/schema registry migration before expecting the Workers Builds fix to succeed end-to-end.

✅ Actions performed

Review triggered.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.