feat(sdk): Add lib version to any outgoing requests for debugging purposes - #1112
Merged
Conversation
Contributor
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Contributor
|
Important Review skippedAuto incremental reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the Use the checkbox below for a quick retry:
📝 WalkthroughWalkthroughThis pull request introduces centralized version header tracking across Python and TypeScript SDKs. New HTTP utility modules are added to expose version headers that capture installed CUA package versions, which are then integrated into API requests throughout both codebases. Documentation versions are bumped across multiple SDK reference materials. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
Contributor
📦 Publishable packages changed
Add |
Codecov Report❌ Patch coverage is 📢 Thoughts on this report? Let us know! |
Contributor
📦 Publishable packages changed
Add |
r33drichards
approved these changes
Feb 25, 2026
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 4
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
libs/python/agent/agent/adapters/cua_adapter.py (1)
1-9:⚠️ Potential issue | 🔴 CriticalFix import ordering to resolve the CI lint failure.
The
from core.http import cua_version_headersimport is separated from the other third-party imports by a blank line, which isort flags as incorrectly sorted/formatted.🐛 Proposed fix
import os from typing import Any, AsyncIterator, Iterator from litellm import acompletion, completion from litellm.llms.custom_llm import CustomLLM from litellm.types.utils import GenericStreamingChunk, ModelResponse - -from core.http import cua_version_headers - +from core.http import cua_version_headers🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@libs/python/agent/agent/adapters/cua_adapter.py` around lines 1 - 9, The import ordering is wrong: move the local import "from core.http import cua_version_headers" so it sits with the third-party imports (adjacent to the litellm imports) following standard isort groups (stdlib, third-party, local) and remove the extra blank line separating it; update the imports in libs/python/agent/agent/adapters/cua_adapter.py so that os and typing remain first, the litellm imports follow, and cua_version_headers is placed directly after the litellm imports.
🧹 Nitpick comments (3)
libs/typescript/playground/src/hooks/useAgentRequest.ts (1)
10-13: Prefer sharedcuaVersionHeadersover local hardcoded header construction.This avoids drift and keeps header behavior consistent across packages (the two usages at Line 43 and Line 73 then inherit the shared logic automatically).
♻️ Suggested refactor
import { useRef, useCallback } from 'react'; +import { cuaVersionHeaders } from '@trycua/core'; import { usePlayground, useChat, useChatDispatch } from './usePlayground'; import { usePlaygroundTelemetry } from '../telemetry'; import type { AgentMessage, UserMessage } from '../types'; import { isVM, isCustomComputer } from '../types'; -const CUA_VERSION_HEADERS: Record<string, string> = { - 'X-Cua-Client-Version': `playground:${__CUA_VERSION__}`, -}; +const CUA_VERSION_HEADERS = cuaVersionHeaders('playground', __CUA_VERSION__);🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@libs/typescript/playground/src/hooks/useAgentRequest.ts` around lines 10 - 13, Replace the local hardcoded CUA_VERSION_HEADERS with the shared cuaVersionHeaders export and use that in the useAgentRequest implementation so both header usages (the spots currently referencing CUA_VERSION_HEADERS around the two header builds) inherit the centralized logic; remove the local CUA_VERSION_HEADERS constant, import cuaVersionHeaders, and update the code paths in useAgentRequest that previously referenced CUA_VERSION_HEADERS to use the imported cuaVersionHeaders symbol instead.libs/python/cua-cli/cua_cli/commands/auth.py (1)
164-164: Consider extracting the header construction to improve readability.The header dict on this line is getting long; splitting it into a local variable is more consistent with the
_base_headers()pattern used in other changed files.♻️ Suggested refactor
- headers = {"Authorization": f"Bearer {api_key}", "Accept": "application/json", **cua_version_headers()} + headers = { + "Authorization": f"Bearer {api_key}", + "Accept": "application/json", + **cua_version_headers(), + }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@libs/python/cua-cli/cua_cli/commands/auth.py` at line 164, Extract the long inline header dict into a local variable for readability: call the existing _base_headers() (or create one if missing) into a local base_headers variable, then set headers = {**base_headers, "Authorization": f"Bearer {api_key}", "Accept": "application/json"} (reusing cua_version_headers() if that function is required to populate base headers). Update the code in auth.py where headers is built to use this local variable and keep the same keys and ordering.libs/python/agent/agent/adapters/cua_adapter.py (1)
78-81: Extract the repeated header-injection block into a private helper.The same 4-line pattern is copy-pasted across all four dispatch methods. A small helper avoids future drift when the version-header logic changes.
♻️ Proposed refactor
+ def _apply_version_headers(self, params: dict) -> None: + """Merge CUA version headers into params, preserving caller-supplied headers.""" + version_hdrs = cua_version_headers() + if version_hdrs: + params["headers"] = {**version_hdrs, **params.get("headers", {})} + def completion(self, *args, **kwargs) -> ModelResponse: ... - # Always include CUA version headers - version_hdrs = cua_version_headers() - if version_hdrs: - params["headers"] = {**version_hdrs, **params.get("headers", {})} + self._apply_version_headers(params) ... async def acompletion(self, *args, **kwargs) -> ModelResponse: ... - # Always include CUA version headers - version_hdrs = cua_version_headers() - if version_hdrs: - params["headers"] = {**version_hdrs, **params.get("headers", {})} + self._apply_version_headers(params) ... def streaming(self, *args, **kwargs) -> Iterator[GenericStreamingChunk]: ... - # Always include CUA version headers - version_hdrs = cua_version_headers() - if version_hdrs: - params["headers"] = {**version_hdrs, **params.get("headers", {})} + self._apply_version_headers(params) ... async def astreaming(self, *args, **kwargs) -> AsyncIterator[GenericStreamingChunk]: ... - # Always include CUA version headers - version_hdrs = cua_version_headers() - if version_hdrs: - params["headers"] = {**version_hdrs, **params.get("headers", {})} + self._apply_version_headers(params) ...Also applies to: 140-143, 181-184, 201-204
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@libs/python/agent/agent/adapters/cua_adapter.py` around lines 78 - 81, Extract the repeated 4-line header-injection pattern into a single private helper (e.g., _inject_cua_version_headers) that calls cua_version_headers(), and if non-empty merges it with params.get("headers", {}) and sets params["headers"]; then replace the duplicated blocks in all dispatch methods (the four occurrences around the existing dispatch_* functions in cua_adapter.py) with a call to that helper so the header merge logic lives in one place.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@libs/python/cua-cli/cua_cli/commands/do.py`:
- Around line 338-341: The local import block is split causing an isort/I001
lint error; make the imports contiguous by placing the local import "from
core.http import cua_version_headers" immediately adjacent to other local
imports (or group it with "import aiohttp" as appropriate), removing the stray
blank line so the import block for aiohttp and cua_version_headers is
continuous.
In `@libs/typescript/agent/src/client.ts`:
- Line 2: The import of cuaVersionHeaders in client.ts fails because
`@trycua/core`'s built output is missing; run a build for that package so its
dist/ entrypoint and type definitions are generated (e.g., run pnpm build in the
libs/typescript/core package) so the symbol cuaVersionHeaders can be resolved
from the package's dist/index.js before merging.
In `@libs/typescript/cua-cli/src/http.ts`:
- Line 1: The module currently does a synchronous import-time read using
readFileSync and relies on a non-existent build define __CUA_VERSION__; instead
create an async getter (e.g., getCliVersion) that uses Bun.file(...).text() to
read the version lazily, replace the import-time read with that function, and
update CUA_VERSION_HEADERS to call await getCliVersion() where headers are
constructed (or, if startup synchronous behavior is required, add
__CUA_VERSION__ as a build define in bunfig.toml). Ensure references include the
symbols CUA_VERSION_HEADERS, getCliVersion, and __CUA_VERSION__ so you can
locate and update their usages.
In `@libs/typescript/playground/tsdown.config.ts`:
- Line 4: The package.json read uses a CWD-relative path which can resolve the
wrong file; change the line that declares pkg (const pkg =
JSON.parse(readFileSync('./package.json', 'utf-8')); ) to read package.json
relative to the tsdown.config.ts file by using __dirname + path join (import or
require 'path' and use join(__dirname, 'package.json')) so the JSON is read from
the file's directory; apply the same pattern used in
libs/typescript/cua-cli/src/http.ts and mirror this fix in the other
tsdown.config.ts files (core, agent, computer).
---
Outside diff comments:
In `@libs/python/agent/agent/adapters/cua_adapter.py`:
- Around line 1-9: The import ordering is wrong: move the local import "from
core.http import cua_version_headers" so it sits with the third-party imports
(adjacent to the litellm imports) following standard isort groups (stdlib,
third-party, local) and remove the extra blank line separating it; update the
imports in libs/python/agent/agent/adapters/cua_adapter.py so that os and typing
remain first, the litellm imports follow, and cua_version_headers is placed
directly after the litellm imports.
---
Nitpick comments:
In `@libs/python/agent/agent/adapters/cua_adapter.py`:
- Around line 78-81: Extract the repeated 4-line header-injection pattern into a
single private helper (e.g., _inject_cua_version_headers) that calls
cua_version_headers(), and if non-empty merges it with params.get("headers", {})
and sets params["headers"]; then replace the duplicated blocks in all dispatch
methods (the four occurrences around the existing dispatch_* functions in
cua_adapter.py) with a call to that helper so the header merge logic lives in
one place.
In `@libs/python/cua-cli/cua_cli/commands/auth.py`:
- Line 164: Extract the long inline header dict into a local variable for
readability: call the existing _base_headers() (or create one if missing) into a
local base_headers variable, then set headers = {**base_headers,
"Authorization": f"Bearer {api_key}", "Accept": "application/json"} (reusing
cua_version_headers() if that function is required to populate base headers).
Update the code in auth.py where headers is built to use this local variable and
keep the same keys and ordering.
In `@libs/typescript/playground/src/hooks/useAgentRequest.ts`:
- Around line 10-13: Replace the local hardcoded CUA_VERSION_HEADERS with the
shared cuaVersionHeaders export and use that in the useAgentRequest
implementation so both header usages (the spots currently referencing
CUA_VERSION_HEADERS around the two header builds) inherit the centralized logic;
remove the local CUA_VERSION_HEADERS constant, import cuaVersionHeaders, and
update the code paths in useAgentRequest that previously referenced
CUA_VERSION_HEADERS to use the imported cuaVersionHeaders symbol instead.
ℹ️ Review info
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (29)
libs/python/agent/agent/adapters/cua_adapter.pylibs/python/computer-server/computer_server/main.pylibs/python/computer/computer/interface/generic.pylibs/python/computer/computer/providers/cloud/provider.pylibs/python/computer/computer/providers/cloud/providerv2.pylibs/python/core/core/__init__.pylibs/python/core/core/http.pylibs/python/cua-cli/cua_cli/api/client.pylibs/python/cua-cli/cua_cli/commands/auth.pylibs/python/cua-cli/cua_cli/commands/do.pylibs/python/cua-cli/cua_cli/commands/mcp.pylibs/python/cua-cli/cua_cli/commands/sandbox.pylibs/typescript/agent/src/client.tslibs/typescript/agent/src/globals.d.tslibs/typescript/agent/tsdown.config.tslibs/typescript/computer/src/computer/providers/cloud.tslibs/typescript/computer/src/globals.d.tslibs/typescript/computer/tsdown.config.tslibs/typescript/core/src/globals.d.tslibs/typescript/core/src/http.tslibs/typescript/core/src/index.tslibs/typescript/core/tsdown.config.tslibs/typescript/cua-cli/src/commands/sandbox.tslibs/typescript/cua-cli/src/http.tslibs/typescript/playground/src/adapters/cloud.tslibs/typescript/playground/src/globals.d.tslibs/typescript/playground/src/hooks/useAgentRequest.tslibs/typescript/playground/src/styles.csslibs/typescript/playground/tsdown.config.ts
Comment on lines
338
to
+341
| import aiohttp | ||
|
|
||
| from core.http import cua_version_headers | ||
|
|
Contributor
There was a problem hiding this comment.
Fix local import block formatting to unblock lint.
Line [338]-Line [341] has a split local import block; this is likely the I001/isort failure in CI. Keep the imports contiguous.
🔧 Proposed fix
import aiohttp
-
from core.http import cua_version_headers📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| import aiohttp | |
| from core.http import cua_version_headers | |
| import aiohttp | |
| from core.http import cua_version_headers |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@libs/python/cua-cli/cua_cli/commands/do.py` around lines 338 - 341, The local
import block is split causing an isort/I001 lint error; make the imports
contiguous by placing the local import "from core.http import
cua_version_headers" immediately adjacent to other local imports (or group it
with "import aiohttp" as appropriate), removing the stray blank line so the
import block for aiohttp and cua_version_headers is continuous.
| @@ -1,4 +1,5 @@ | |||
| import { Peer } from 'peerjs'; | |||
| import { cuaVersionHeaders } from '@trycua/core'; | |||
Contributor
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== Source exports =="
rg -n "export \\* from './http'|export function cuaVersionHeaders|CUA_CLIENT_VERSION_HEADER" libs/typescript/core/src -C2
echo
echo "== Core package entrypoints/exports =="
fd '^package\.json$' libs/typescript/core --exec sh -c '
echo "---- $1 ----"
jq "{name, main, module, types, exports}" "$1"
' sh {}
echo
echo "== Declared type surface in repo =="
rg -n "cuaVersionHeaders" libs/typescript/core -g '*.d.ts' -C2 || trueRepository: trycua/cua
Length of output: 1277
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== Core package.json (full) =="
cat libs/typescript/core/package.json
echo
echo "== Check if built .d.ts exists =="
find libs/typescript/core -name "*.d.ts" -type f 2>/dev/null | head -20 || echo "No .d.ts files found"
echo
echo "== Check dist/lib structure =="
ls -la libs/typescript/core/ 2>/dev/null | grep -E "^d|package.json|tsconfig" || echo "No dist/lib directories"Repository: trycua/cua
Length of output: 1890
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== Dist folder structure =="
if [ -d "libs/typescript/core/dist" ]; then
ls -la libs/typescript/core/dist/
echo
echo "== Check if index.d.ts contains cuaVersionHeaders =="
grep -n "cuaVersionHeaders" libs/typescript/core/dist/index.d.ts 2>/dev/null || echo "NOT FOUND in index.d.ts"
else
echo "dist/ folder does NOT exist"
fi
echo
echo "== Check where the agent is trying to import from =="
rg "import.*cuaVersionHeaders" libs/typescript/agent/src/ -C2Repository: trycua/cua
Length of output: 485
Build @trycua/core before merge.
The cuaVersionHeaders export exists in source (libs/typescript/core/src/http.ts), but the dist/ folder has not been built. The package is configured to use dist/index.js as its entrypoint, so without the build output, this import cannot resolve.
Run pnpm build in libs/typescript/core/ to generate the dist folder and type definitions.
🧰 Tools
🪛 GitHub Actions: CI: Lint TypeScript
[error] 2-2: tsc --noEmit: Module '@trycua/core' has no exported member 'cuaVersionHeaders'.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@libs/typescript/agent/src/client.ts` at line 2, The import of
cuaVersionHeaders in client.ts fails because `@trycua/core`'s built output is
missing; run a build for that package so its dist/ entrypoint and type
definitions are generated (e.g., run pnpm build in the libs/typescript/core
package) so the symbol cuaVersionHeaders can be resolved from the package's
dist/index.js before merging.
| @@ -1,12 +1,22 @@ | |||
| import { readFileSync } from 'node:fs'; | |||
Contributor
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Check if the file exists and show its content
echo "=== Content of libs/typescript/cua-cli/src/http.ts ==="
if [ -f "libs/typescript/cua-cli/src/http.ts" ]; then
head -20 libs/typescript/cua-cli/src/http.ts
else
echo "File not found, searching for it..."
find . -name "http.ts" -type f 2>/dev/null | head -5
fi
echo -e "\n=== Check for __CUA_VERSION__ definition ==="
rg -n "__CUA_VERSION__" libs/typescript/cua-cli -g '*.ts' -g '*.d.ts' -g '*.tsx' -g '*.js' || echo "Not found"
echo -e "\n=== Check build configuration files ==="
ls -la libs/typescript/cua-cli/ | grep -E "build|tsconfig|bunfig|vite" || true
echo -e "\n=== Check for bunfig or build configuration ==="
find libs/typescript/cua-cli -maxdepth 2 -type f \( -name "bunfig.toml" -o -name "tsconfig.json" -o -name "build.ts" \) -exec echo "Found: {}" \;Repository: trycua/cua
Length of output: 974
🏁 Script executed:
#!/bin/bash
# Check package.json structure and version field
echo "=== Check package.json in cua-cli ==="
cat libs/typescript/cua-cli/package.json | head -15
echo -e "\n=== Check root package.json ==="
cat package.json | grep -A2 '"version"' | head -5Repository: trycua/cua
Length of output: 711
Replace node:fs with async file read; __CUA_VERSION__ build injection is not currently wired.
The import-time readFileSync violates the cua-cli guideline to use Bun.file over node:fs, and a synchronous file read at module initialization can fail during startup.
However, the proposed build-time __CUA_VERSION__ injection does not currently exist in the build configuration. A practical alternative is to defer the version read until first use:
-import { readFileSync } from 'node:fs';
import { API_BASE } from './config';
-const { version: cliVersion } = JSON.parse(
- readFileSync(new URL('../../package.json', import.meta.url), 'utf-8')
-) as { version: string };
+let cliVersion: string | null = null;
+
+async function getCliVersion(): Promise<string> {
+ if (cliVersion === null) {
+ try {
+ const file = Bun.file(new URL('../../package.json', import.meta.url));
+ const pkg = JSON.parse(await file.text()) as { version: string };
+ cliVersion = pkg.version;
+ } catch {
+ cliVersion = 'unknown';
+ }
+ }
+ return cliVersion;
+}Then update CUA_VERSION_HEADERS to use await getCliVersion() where needed, or if synchronous initialization is required, implement __CUA_VERSION__ as a build define in bunfig.toml.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@libs/typescript/cua-cli/src/http.ts` at line 1, The module currently does a
synchronous import-time read using readFileSync and relies on a non-existent
build define __CUA_VERSION__; instead create an async getter (e.g.,
getCliVersion) that uses Bun.file(...).text() to read the version lazily,
replace the import-time read with that function, and update CUA_VERSION_HEADERS
to call await getCliVersion() where headers are constructed (or, if startup
synchronous behavior is required, add __CUA_VERSION__ as a build define in
bunfig.toml). Ensure references include the symbols CUA_VERSION_HEADERS,
getCliVersion, and __CUA_VERSION__ so you can locate and update their usages.
| import { readFileSync } from 'node:fs'; | ||
| import { defineConfig } from 'tsdown'; | ||
|
|
||
| const pkg = JSON.parse(readFileSync('./package.json', 'utf-8')); |
Contributor
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# 1. Check if the target file exists and show its content
echo "=== Checking target file ==="
if [ -f "libs/typescript/playground/tsdown.config.ts" ]; then
echo "File exists:"
cat -n "libs/typescript/playground/tsdown.config.ts"
else
echo "File not found at libs/typescript/playground/tsdown.config.ts"
fi
echo ""
echo "=== Searching for all tsdown.config.ts files ==="
fd "tsdown.config.ts" libs/typescript
echo ""
echo "=== Checking for readFileSync patterns with package.json in tsdown configs ==="
rg -n "readFileSync.*package\.json" libs/typescript --glob "**tsdown.config.ts" -B 2 -A 2Repository: trycua/cua
Length of output: 2907
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "=== Checking for package.json files in libs/typescript ==="
fd "package\.json" libs/typescript | head -20
echo ""
echo "=== Looking at package.json structure ==="
find libs/typescript -name "package.json" -exec sh -c 'echo "=== {} ===" && head -3 {}' \;
echo ""
echo "=== Checking build scripts and how tsdown is invoked ==="
rg "tsdown" --glob "*.json" --glob "*.ts" --glob "*.md" libs/typescript -B 1 -A 1 | head -40
echo ""
echo "=== Check if there's a root build script or config ==="
find . -maxdepth 2 -name "package.json" -o -name "*.config.ts" -o -name "Makefile" | grep -E "(package\.json|build|tsdown)" | head -10Repository: trycua/cua
Length of output: 3243
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "=== Check root package.json for workspace or build orchestration ==="
head -50 ./package.json
echo ""
echo "=== Look for pnpm-workspace.yaml or similar ==="
fd "pnpm-workspace|lerna|nx\.json" . --maxdepth 2
echo ""
echo "=== Check if any root-level build scripts invoke tsdown ==="
rg "tsdown" ./package.json
echo ""
echo "=== Verify if import.meta.url is accessible in tsdown context ==="
# Check TypeScript version and target
grep -A 5 "compilerOptions" libs/typescript/playground/tsconfig.json 2>/dev/null | head -20Repository: trycua/cua
Length of output: 560
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "=== Search for tsconfig files ==="
fd "tsconfig" libs/typescript
echo ""
echo "=== Check build context: where is npm/pnpm build invoked from? ==="
# Look at CI/build scripts
fd "\.yml|\.yaml|Makefile" . --maxdepth 3 | grep -E "(github|gitlab|circleci|build|workflow)" | head -10
echo ""
echo "=== Check if there are CI workflows that build packages ==="
find . -path "./.github/workflows" -name "*.yml" 2>/dev/null | head -5
echo ""
echo "=== Examine a specific package.json build script ==="
cat libs/typescript/playground/package.json | jq '.scripts'
echo ""
echo "=== Key question: Does CWD matter? Check if builds are run per-package or from root ==="
# Search for any documentation or build instructions
fd "README|BUILD|CONTRIBUTING" libs/typescript --maxdepth 2Repository: trycua/cua
Length of output: 344
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "=== Check Node.js target and ESM support in tsconfig ==="
cat libs/typescript/playground/tsconfig.json | jq '.compilerOptions | {module, target, lib}'
echo ""
echo "=== Verify import.meta is supported ==="
rg "import\.meta" libs/typescript --glob "**/*.ts" | head -5
echo ""
echo "=== Check if the proposed fix syntax is correct by looking for similar patterns ==="
rg "new URL.*import\.meta\.url" --glob "**/*.ts" --glob "**/*.js"
echo ""
echo "=== Check .npmrc or pnpm config for workspace behavior ==="
cat .npmrc 2>/dev/null || echo "No .npmrc found"
cat pnpm-workspace.yaml 2>/dev/null || echo "No pnpm-workspace.yaml found"Repository: trycua/cua
Length of output: 322
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "=== Check Node.js target and ESM support in tsconfig ==="
cat libs/typescript/playground/tsconfig.json
echo ""
echo "=== Verify import.meta is supported ==="
rg "import\.meta" libs/typescript --glob "**/*.ts" | head -5
echo ""
echo "=== Check if the proposed fix syntax is correct by looking for similar patterns ==="
rg "new URL.*import\.meta\.url" --glob "**/*.ts" --glob "**/*.js"
echo ""
echo "=== Check for monorepo structure ==="
ls -la pnpm-workspace.yaml 2>/dev/null || echo "No pnpm-workspace.yaml found"Repository: trycua/cua
Length of output: 1095
Anchor package.json resolution to file location in all tsdown configs.
All four tsdown.config.ts files (playground, core, agent, computer) use CWD-relative paths that can inject the wrong version if builds run from a different working directory. The __CUA_VERSION__ constant gets injected into production code, so this is a real issue.
Use the pattern already established in libs/typescript/cua-cli/src/http.ts:
🔧 Proposed fix
Apply to libs/typescript/{playground,core,agent,computer}/tsdown.config.ts line 4:
-const pkg = JSON.parse(readFileSync('./package.json', 'utf-8'));
+const pkg = JSON.parse(
+ readFileSync(new URL('./package.json', import.meta.url), 'utf-8')
+) as { version: string };📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| const pkg = JSON.parse(readFileSync('./package.json', 'utf-8')); | |
| const pkg = JSON.parse( | |
| readFileSync(new URL('./package.json', import.meta.url), 'utf-8') | |
| ) as { version: string }; |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@libs/typescript/playground/tsdown.config.ts` at line 4, The package.json read
uses a CWD-relative path which can resolve the wrong file; change the line that
declares pkg (const pkg = JSON.parse(readFileSync('./package.json', 'utf-8')); )
to read package.json relative to the tsdown.config.ts file by using __dirname +
path join (import or require 'path' and use join(__dirname, 'package.json')) so
the JSON is read from the file's directory; apply the same pattern used in
libs/typescript/cua-cli/src/http.ts and mirror this fix in the other
tsdown.config.ts files (core, agent, computer).
Contributor
📦 Publishable packages changed
Add |
Contributor
📦 Publishable packages changed
Add |
Contributor
There was a problem hiding this comment.
Actionable comments posted: 6
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
docs/content/docs/cuabench/reference/api.mdx (1)
3634-3656:⚠️ Potential issue | 🟡 MinorAdd
setup_configparameter documentation to the Python source docstring.The parameter
setup_config: Optional[dict] = Noneis present in the method signature (line 402 inlibs/cua-bench/cua_bench/runner/task_runner.py) but is missing from the docstring'sArgs:section. The generator correctly renders what the docstring provides, so the fix must be applied to the Python source, not the generator script.📝 Missing docstring entry
Add this line to the
Args:section inlibs/cua-bench/cua_bench/runner/task_runner.pyafter thetask_indexentry:setup_config: Optional desktop setup configuration dict🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/content/docs/cuabench/reference/api.mdx` around lines 3634 - 3656, The docstring for run_task_interactively is missing documentation for the setup_config parameter; open the run_task_interactively method's docstring and add an Args entry for setup_config immediately after the task_index entry, e.g. "setup_config: Optional desktop setup configuration dict", matching the surrounding docstring style and formatting so the generated docs include this parameter; ensure the symbol run_task_interactively and its signature (setup_config: Optional[dict] = None) remain consistent.
♻️ Duplicate comments (4)
libs/typescript/playground/tsdown.config.ts (1)
4-4: CWD-relativepackage.jsonpath was already flagged.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@libs/typescript/playground/tsdown.config.ts` at line 4, The code reads package.json via a CWD-relative path (const pkg = JSON.parse(readFileSync('./package.json', 'utf-8'))), which is brittle; change it to compute a module-relative absolute path (import/require path and use path.resolve or path.join with __dirname) and read that instead. Specifically, update tsdown.config.ts to import path, build the package path using path.resolve(__dirname, '../package.json') (or equivalent module-url handling if ESM), and pass that absolute path into readFileSync so pkg is loaded reliably regardless of current working directory.libs/typescript/cua-cli/src/http.ts (1)
1-10:⚠️ Potential issue | 🟠 MajorAvoid
node:fsimport-time version reads in cua-cli HTTP module.This is still doing a synchronous filesystem read during module initialization, which is brittle in bundled/distributed layouts and does not follow the cua-cli Bun guideline.
🔧 Suggested direction
-import { readFileSync } from 'node:fs'; import { API_BASE } from './config'; -const { version: cliVersion } = JSON.parse( - readFileSync(new URL('../../package.json', import.meta.url), 'utf-8') -) as { version: string }; +const cliVersion = __CUA_VERSION__;Then inject
__CUA_VERSION__for cua-cli at build time (same pattern used in other TS packages in this PR).#!/bin/bash set -euo pipefail echo "=== node:fs usage in cua-cli http ===" rg -n "node:fs|readFileSync" libs/typescript/cua-cli/src/http.ts echo echo "=== __CUA_VERSION__ usage/declaration inside cua-cli ===" rg -n "__CUA_VERSION__" libs/typescript/cua-cli -g '*.ts' -g '*.tsx' -g '*.d.ts' || true echo echo "=== cua-cli build config files that could inject defines ===" fd "^(tsdown\\.config\\.ts|bunfig\\.toml|build\\.ts|package\\.json)$" libs/typescript/cua-cliAs per coding guidelines: “Prefer
Bun.fileovernode:fs's readFile/writeFile for file operations” forlibs/typescript/cua-cli/**/*.{ts,tsx,js,jsx}.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@libs/typescript/cua-cli/src/http.ts` around lines 1 - 10, The module currently performs a synchronous filesystem read at import time via readFileSync and node:fs to extract package.json and build CUA_VERSION_HEADERS (symbols: readFileSync, cliVersion, CUA_VERSION_HEADERS); replace this with a build-time injected constant __CUA_VERSION__ (same pattern used in other TS packages) and remove the readFileSync/node:fs import: compute CUA_VERSION_HEADERS using __CUA_VERSION__ (e.g. `cli:${__CUA_VERSION__}`) so no fs I/O happens during module initialization and the header logic remains in the exported CUA_VERSION_HEADERS.libs/python/computer/computer/providers/cloud/provider.py (2)
25-25: Same absolutecore.httpimport concern applies here.Same observation as in
providerv2.py— the absolutefrom core.http import cua_version_headersis inconsistent with the relative imports used elsewhere in this file.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@libs/python/computer/computer/providers/cloud/provider.py` at line 25, The file uses an absolute import "from core.http import cua_version_headers" which is inconsistent with the relative imports used elsewhere (same issue as in providerv2.py); replace that absolute import with the matching relative import style used in this package (import the symbol cua_version_headers via a relative import so it aligns with the other imports in this module).
58-63: Duplicate ofCloudV2Provider._base_headers— same refactor applies.This implementation is byte-for-byte identical to the one in
providerv2.py. See the comment there for the proposed lift toBaseVMProvider.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@libs/python/computer/computer/providers/cloud/provider.py` around lines 58 - 63, The _base_headers implementation is duplicated in CloudV2Provider (providerv2.py) and Cloud provider.py; move this method up into the shared BaseVMProvider so both providers inherit a single implementation: add _base_headers(self) -> Dict[str, str] to BaseVMProvider, remove the duplicate _base_headers from CloudV2Provider and Cloud provider.py, and ensure any required utilities (cua_version_headers, api_key attribute) remain accessible to BaseVMProvider via existing imports/attributes.
🧹 Nitpick comments (4)
libs/python/cua-cli/cua_cli/commands/mcp.py (1)
445-446: Movecua_version_headersimport to module level.The import is buried inside
_send_command, a hot inner function called on every computer tool invocation. This is inconsistent with all other call sites in this PR. Moving it to module level is zero-risk and aligns with the pattern everywhere else.♻️ Proposed refactor
Add to the top-level imports:
+from core.http import cua_version_headersRemove the local import inside
_send_command:async def _send_command(sandbox_name: str, command: str, params: dict) -> dict: """Send a command to the computer-server.""" server_url = await _get_server_url(sandbox_name) api_key = get_api_key() - from core.http import cua_version_headers - headers = {🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@libs/python/cua-cli/cua_cli/commands/mcp.py` around lines 445 - 446, Move the local import of cua_version_headers out of the hot inner function _send_command and add it to the module-level imports in cua_cli.commands.mcp; specifically, remove the "from core.http import cua_version_headers" from inside _send_command and place a single top-of-file import for cua_version_headers with the other imports so the symbol is imported once at module load rather than on every tool invocation.libs/python/computer-server/computer_server/main.py (1)
273-274: Movecua_version_headersimport to module level for consistency.Every other call site in this PR imports
cua_version_headersat module level. The current placement insideauth()is unusual and forces a name lookup on each authentication call, even though Python caches modules after the first import.♻️ Proposed refactor
Add to the existing top-level imports (alongside
from core.telemetry import record_event):+from core.http import cua_version_headers from core.telemetry import record_eventThen remove the local import in
auth():try: - from core.http import cua_version_headers - async with aiohttp.ClientSession() as session: headers = {"Authorization": f"Bearer {api_key}", **cua_version_headers()}🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@libs/python/computer-server/computer_server/main.py` around lines 273 - 274, Move the local import of cua_version_headers out of the auth() function and add it to the module-level imports alongside existing top-level imports (e.g., next to from core.telemetry import record_event); then remove the in-function import statement inside auth() so auth() references cua_version_headers from the module scope.libs/python/core/core/http.py (1)
26-35: Optional: cache the returned dict to avoid repeated allocations on hot paths.
_build_version_stringis cached, butcua_version_headers()allocates a newdicton every call. Since the result is immutable (version data never changes at runtime), wrappingcua_version_headerswith@lru_cache(maxsize=1)eliminates the allocation entirely. Note that callers using**cua_version_headers()would still unpack a fresh reference but the underlying dict would be the same object.♻️ Proposed refactor
+@lru_cache(maxsize=1) def cua_version_headers() -> dict[str, str]:🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@libs/python/core/core/http.py` around lines 26 - 35, Cua_version_headers currently builds and returns a new dict on every call; make it return a cached immutable dict to avoid repeated allocations by decorating cua_version_headers with functools.lru_cache(maxsize=1) (or equivalent) so the single dict containing {CUA_CLIENT_VERSION_HEADER: _build_version_string()} is reused; ensure you still call _build_version_string() inside the function and only return {} when value is falsy, keeping the same behavior for callers that unpack with **cua_version_headers().libs/python/computer/computer/providers/cloud/providerv2.py (1)
52-57:_base_headersis duplicated verbatim betweenCloudV2ProviderandCloudProvider— lift it toBaseVMProvider.Both providers inherit from
BaseVMProviderand initialiseself.api_keyidentically. The method body is bit-for-bit the same in both classes, which creates a maintenance hazard (e.g., adding a new header must be done in two places).♻️ Proposed refactor — move helper to `BaseVMProvider`
In
BaseVMProvider(e.g.,libs/python/computer/computer/providers/base.py):+ from core.http import cua_version_headers + + def _base_headers(self) -> Dict[str, str]: + return { + "Authorization": f"Bearer {self.api_key}", + "Accept": "application/json", + **cua_version_headers(), + }Then remove the duplicated method from both
CloudProviderandCloudV2Provider:- def _base_headers(self) -> Dict[str, str]: - return { - "Authorization": f"Bearer {self.api_key}", - "Accept": "application/json", - **cua_version_headers(), - }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@libs/python/computer/computer/providers/cloud/providerv2.py` around lines 52 - 57, Move the duplicated _base_headers implementation into the common BaseVMProvider class and remove the copies from CloudProvider and CloudV2Provider: add a single _base_headers(self) method on BaseVMProvider that returns {"Authorization": f"Bearer {self.api_key}", "Accept": "application/json", **cua_version_headers()} (import cua_version_headers where needed) so both CloudProvider and CloudV2Provider inherit it and you can delete their local _base_headers implementations.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@libs/python/computer/computer/providers/cloud/providerv2.py`:
- Line 21: Replace the absolute import "from core.http import
cua_version_headers" with a relative import to match the other intra-package
imports; update the import in providerv2.py to import cua_version_headers using
the appropriate relative path (similar to the existing "from ..base" and "from
..types" style) so the module no longer depends on core being on sys.path and
remains resilient to packaging changes.
In `@libs/python/cua-cli/cua_cli/commands/auth.py`:
- Line 164: The headers assignment in auth.py (the "headers" variable where
Authorization, Accept and cua_version_headers() are combined) exceeds Black's
line-length and fails CI; reformat that assignment to wrap the dict across
multiple lines (or otherwise shorten the expression) so it conforms to Black's
max-line-length and then run `black
libs/python/cua-cli/cua_cli/commands/auth.py` (or run project-wide Black) to
apply the proper formatting.
In `@libs/typescript/agent/tsdown.config.ts`:
- Line 4: Replace the cwd-relative read of package.json with a path resolved
relative to this config file: instead of readFileSync('./package.json', ...),
use readFileSync(path.resolve(__dirname, 'package.json'), 'utf-8')
(import/ensure you have imported path and fs). Update the code that initializes
pkg (the const pkg = JSON.parse(...)) to use path.resolve(__dirname,
'package.json') so the package version is read relative to tsdown.config.ts
rather than the process CWD.
In `@libs/typescript/computer/src/computer/providers/cloud.ts`:
- Line 67: fetchAndCacheHost currently references the build-injected constant
__CUA_VERSION__ directly when calling cuaVersionHeaders('computer',
__CUA_VERSION__), which can throw a ReferenceError outside build contexts (e.g.,
tests). Change the call to guard against missing global by using a typeof check
and a fallback (e.g., typeof __CUA_VERSION__ !== 'undefined' ? __CUA_VERSION__ :
'' or undefined) so cuaVersionHeaders receives a safe value; update the
invocation inside fetchAndCacheHost to use that guarded expression.
In `@libs/typescript/computer/tsdown.config.ts`:
- Line 4: The code in tsdown.config.ts reads package.json via a CWD-relative
path (const pkg = JSON.parse(readFileSync('./package.json', 'utf-8'))), which is
brittle; change it to compute the package.json path relative to this module so
it is CWD-independent—e.g., replace the readFileSync('./package.json', ...) call
with reading via a URL resolved from import.meta.url (or the runtime-equivalent)
such as readFileSync(new URL('../package.json', import.meta.url), 'utf-8') and
keep assigning to pkg; ensure the change targets the const pkg assignment in
tsdown.config.ts so package.json is loaded relative to the config file rather
than the current working directory.
In `@libs/typescript/core/tsdown.config.ts`:
- Line 4: The current pkg load uses a CWD-dependent path (const pkg =
JSON.parse(readFileSync('./package.json', 'utf-8'));), which can pick up the
wrong manifest in monorepos—change the readFileSync call in each
tsdown.config.ts to resolve package.json relative to the config file (e.g., use
path.resolve(__dirname, '../package.json') or path.join(__dirname,
'package.json') as appropriate) before JSON.parse so pkg is always loaded from
the config's package.json; update the import/require usage to include Node's
path and ensure the same change is applied in the four tsdown.config.ts files
(core, agent, computer, playground).
---
Outside diff comments:
In `@docs/content/docs/cuabench/reference/api.mdx`:
- Around line 3634-3656: The docstring for run_task_interactively is missing
documentation for the setup_config parameter; open the run_task_interactively
method's docstring and add an Args entry for setup_config immediately after the
task_index entry, e.g. "setup_config: Optional desktop setup configuration
dict", matching the surrounding docstring style and formatting so the generated
docs include this parameter; ensure the symbol run_task_interactively and its
signature (setup_config: Optional[dict] = None) remain consistent.
---
Duplicate comments:
In `@libs/python/computer/computer/providers/cloud/provider.py`:
- Line 25: The file uses an absolute import "from core.http import
cua_version_headers" which is inconsistent with the relative imports used
elsewhere (same issue as in providerv2.py); replace that absolute import with
the matching relative import style used in this package (import the symbol
cua_version_headers via a relative import so it aligns with the other imports in
this module).
- Around line 58-63: The _base_headers implementation is duplicated in
CloudV2Provider (providerv2.py) and Cloud provider.py; move this method up into
the shared BaseVMProvider so both providers inherit a single implementation: add
_base_headers(self) -> Dict[str, str] to BaseVMProvider, remove the duplicate
_base_headers from CloudV2Provider and Cloud provider.py, and ensure any
required utilities (cua_version_headers, api_key attribute) remain accessible to
BaseVMProvider via existing imports/attributes.
In `@libs/typescript/cua-cli/src/http.ts`:
- Around line 1-10: The module currently performs a synchronous filesystem read
at import time via readFileSync and node:fs to extract package.json and build
CUA_VERSION_HEADERS (symbols: readFileSync, cliVersion, CUA_VERSION_HEADERS);
replace this with a build-time injected constant __CUA_VERSION__ (same pattern
used in other TS packages) and remove the readFileSync/node:fs import: compute
CUA_VERSION_HEADERS using __CUA_VERSION__ (e.g. `cli:${__CUA_VERSION__}`) so no
fs I/O happens during module initialization and the header logic remains in the
exported CUA_VERSION_HEADERS.
In `@libs/typescript/playground/tsdown.config.ts`:
- Line 4: The code reads package.json via a CWD-relative path (const pkg =
JSON.parse(readFileSync('./package.json', 'utf-8'))), which is brittle; change
it to compute a module-relative absolute path (import/require path and use
path.resolve or path.join with __dirname) and read that instead. Specifically,
update tsdown.config.ts to import path, build the package path using
path.resolve(__dirname, '../package.json') (or equivalent module-url handling if
ESM), and pass that absolute path into readFileSync so pkg is loaded reliably
regardless of current working directory.
---
Nitpick comments:
In `@libs/python/computer-server/computer_server/main.py`:
- Around line 273-274: Move the local import of cua_version_headers out of the
auth() function and add it to the module-level imports alongside existing
top-level imports (e.g., next to from core.telemetry import record_event); then
remove the in-function import statement inside auth() so auth() references
cua_version_headers from the module scope.
In `@libs/python/computer/computer/providers/cloud/providerv2.py`:
- Around line 52-57: Move the duplicated _base_headers implementation into the
common BaseVMProvider class and remove the copies from CloudProvider and
CloudV2Provider: add a single _base_headers(self) method on BaseVMProvider that
returns {"Authorization": f"Bearer {self.api_key}", "Accept":
"application/json", **cua_version_headers()} (import cua_version_headers where
needed) so both CloudProvider and CloudV2Provider inherit it and you can delete
their local _base_headers implementations.
In `@libs/python/core/core/http.py`:
- Around line 26-35: Cua_version_headers currently builds and returns a new dict
on every call; make it return a cached immutable dict to avoid repeated
allocations by decorating cua_version_headers with
functools.lru_cache(maxsize=1) (or equivalent) so the single dict containing
{CUA_CLIENT_VERSION_HEADER: _build_version_string()} is reused; ensure you still
call _build_version_string() inside the function and only return {} when value
is falsy, keeping the same behavior for callers that unpack with
**cua_version_headers().
In `@libs/python/cua-cli/cua_cli/commands/mcp.py`:
- Around line 445-446: Move the local import of cua_version_headers out of the
hot inner function _send_command and add it to the module-level imports in
cua_cli.commands.mcp; specifically, remove the "from core.http import
cua_version_headers" from inside _send_command and place a single top-of-file
import for cua_version_headers with the other imports so the symbol is imported
once at module load rather than on every tool invocation.
ℹ️ Review info
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (2)
libs/typescript/pnpm-lock.yamlis excluded by!**/pnpm-lock.yamluv.lockis excluded by!**/*.lock
📒 Files selected for processing (36)
docs/content/docs/cua/reference/agent-sdk/index.mdxdocs/content/docs/cua/reference/cli/index.mdxdocs/content/docs/cua/reference/computer-sdk/index.mdxdocs/content/docs/cuabench/reference/api.mdxlibs/python/agent/agent/adapters/cua_adapter.pylibs/python/computer-server/computer_server/main.pylibs/python/computer/computer/interface/generic.pylibs/python/computer/computer/providers/cloud/provider.pylibs/python/computer/computer/providers/cloud/providerv2.pylibs/python/core/core/__init__.pylibs/python/core/core/http.pylibs/python/cua-cli/cua_cli/api/client.pylibs/python/cua-cli/cua_cli/commands/auth.pylibs/python/cua-cli/cua_cli/commands/do.pylibs/python/cua-cli/cua_cli/commands/mcp.pylibs/python/cua-cli/cua_cli/commands/sandbox.pylibs/typescript/agent/package.jsonlibs/typescript/agent/src/client.tslibs/typescript/agent/src/globals.d.tslibs/typescript/agent/tsdown.config.tslibs/typescript/computer/package.jsonlibs/typescript/computer/src/computer/providers/cloud.tslibs/typescript/computer/src/globals.d.tslibs/typescript/computer/tsdown.config.tslibs/typescript/core/src/globals.d.tslibs/typescript/core/src/http.tslibs/typescript/core/src/index.tslibs/typescript/core/tsdown.config.tslibs/typescript/cua-cli/src/commands/sandbox.tslibs/typescript/cua-cli/src/http.tslibs/typescript/playground/src/adapters/cloud.tslibs/typescript/playground/src/globals.d.tslibs/typescript/playground/src/hooks/useAgentRequest.tslibs/typescript/playground/src/styles.csslibs/typescript/playground/tsdown.config.tspyproject.toml
| import os | ||
|
|
||
| import aiohttp | ||
| from core.http import cua_version_headers |
Contributor
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Search for all absolute imports from core in the providers package
echo "=== Absolute core imports in providers package ==="
rg "from core\." libs/python/computer/computer/providers/ --type py -C 1
# Search for the cua_version_headers specifically
echo -e "\n=== All imports of cua_version_headers ==="
rg "cua_version_headers" libs/python/computer/ --type py -C 1
# Check the target file directly
echo -e "\n=== All imports in providerv2.py ==="
head -30 libs/python/computer/computer/providers/cloud/providerv2.pyRepository: trycua/cua
Length of output: 3171
🏁 Script executed:
#!/bin/bash
# Check project structure and setup files for package configuration
echo "=== Looking for setup.py or pyproject.toml ==="
find libs/python/computer -name "setup.py" -o -name "pyproject.toml" | head -10
# If found, check if they define core as a package
echo -e "\n=== Checking setup files for core package definition ==="
cat libs/python/computer/setup.py 2>/dev/null || echo "No setup.py found in computer/"
cat libs/python/computer/pyproject.toml 2>/dev/null || echo "No pyproject.toml found in computer/"Repository: trycua/cua
Length of output: 1214
🏁 Script executed:
#!/bin/bash
# Check the structure of libs/python to understand namespace
echo "=== Package structure in libs/python ==="
ls -la libs/python/
echo -e "\n=== Contents of libs/python/computer ==="
ls -la libs/python/computer/
echo -e "\n=== Check if core is a sibling package ==="
ls -la libs/python/ | grep -E "^d"Repository: trycua/cua
Length of output: 1905
Use relative imports for consistency with other local imports in this file.
The absolute from core.http import cua_version_headers is inconsistent with other intra-project imports like from ..base import ... and from ..types import .... This pattern appears in multiple files but still depends on core being on sys.path, making imports fragile to packaging restructures. Consider converting to a relative import or centralizing the core module handling across the codebase.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@libs/python/computer/computer/providers/cloud/providerv2.py` at line 21,
Replace the absolute import "from core.http import cua_version_headers" with a
relative import to match the other intra-package imports; update the import in
providerv2.py to import cua_version_headers using the appropriate relative path
(similar to the existing "from ..base" and "from ..types" style) so the module
no longer depends on core being on sys.path and remains resilient to packaging
changes.
| async def _fetch(): | ||
| url = f"{_get_api_base()}/v1/me" | ||
| headers = {"Authorization": f"Bearer {api_key}", "Accept": "application/json"} | ||
| headers = {"Authorization": f"Bearer {api_key}", "Accept": "application/json", **cua_version_headers()} |
Contributor
There was a problem hiding this comment.
CI pipeline failure: Black formatting check fails on this line.
The Lint Python pipeline fails because this line exceeds Black's line-length limit. Run black libs/python/cua-cli/cua_cli/commands/auth.py to fix.
🐛 Proposed fix (Black-formatted)
- headers = {"Authorization": f"Bearer {api_key}", "Accept": "application/json", **cua_version_headers()}
+ headers = {
+ "Authorization": f"Bearer {api_key}",
+ "Accept": "application/json",
+ **cua_version_headers(),
+ }📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| headers = {"Authorization": f"Bearer {api_key}", "Accept": "application/json", **cua_version_headers()} | |
| headers = { | |
| "Authorization": f"Bearer {api_key}", | |
| "Accept": "application/json", | |
| **cua_version_headers(), | |
| } |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@libs/python/cua-cli/cua_cli/commands/auth.py` at line 164, The headers
assignment in auth.py (the "headers" variable where Authorization, Accept and
cua_version_headers() are combined) exceeds Black's line-length and fails CI;
reformat that assignment to wrap the dict across multiple lines (or otherwise
shorten the expression) so it conforms to Black's max-line-length and then run
`black libs/python/cua-cli/cua_cli/commands/auth.py` (or run project-wide Black)
to apply the proper formatting.
| import { readFileSync } from 'node:fs'; | ||
| import { defineConfig } from 'tsdown'; | ||
|
|
||
| const pkg = JSON.parse(readFileSync('./package.json', 'utf-8')); |
Contributor
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# Check the file existence and basic content
ls -la libs/typescript/agent/tsdown.config.ts
# Read the file to see the full context
cat -n libs/typescript/agent/tsdown.config.tsRepository: trycua/cua
Length of output: 794
🏁 Script executed:
# Check the directory structure to understand the monorepo layout
fd -t f 'package.json' libs/typescript/ | head -20Repository: trycua/cua
Length of output: 266
🏁 Script executed:
# Check if there are other tsdown configs in the repo to understand the pattern
fd -t f 'tsdown.config' | head -20Repository: trycua/cua
Length of output: 216
🏁 Script executed:
# Check all tsdown configs
for file in libs/typescript/agent/tsdown.config.ts libs/typescript/computer/tsdown.config.ts libs/typescript/core/tsdown.config.ts libs/typescript/playground/tsdown.config.ts; do
echo "=== $file ==="
cat -n "$file" | grep -A 2 -B 2 "readFileSync\|package.json"
doneRepository: trycua/cua
Length of output: 1120
🏁 Script executed:
# Check the directory structure to understand where these configs and package.json files are relative to each other
cd libs/typescript && find . -maxdepth 2 -type f \( -name "tsdown.config.ts" -o -name "package.json" \) | sortRepository: trycua/cua
Length of output: 289
Resolve package.json relative to the config file, not process CWD.
Using readFileSync('./package.json', ...) reads the path relative to the current working directory, which will fail when the build is invoked from a parent directory in the monorepo. This would inject an incorrect package version into the SDK headers.
🔧 Suggested fix
-const pkg = JSON.parse(readFileSync('./package.json', 'utf-8'));
+const pkg = JSON.parse(readFileSync(new URL('./package.json', import.meta.url), 'utf-8'));📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| const pkg = JSON.parse(readFileSync('./package.json', 'utf-8')); | |
| const pkg = JSON.parse(readFileSync(new URL('./package.json', import.meta.url), 'utf-8')); |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@libs/typescript/agent/tsdown.config.ts` at line 4, Replace the cwd-relative
read of package.json with a path resolved relative to this config file: instead
of readFileSync('./package.json', ...), use readFileSync(path.resolve(__dirname,
'package.json'), 'utf-8') (import/ensure you have imported path and fs). Update
the code that initializes pkg (the const pkg = JSON.parse(...)) to use
path.resolve(__dirname, 'package.json') so the package version is read relative
to tsdown.config.ts rather than the process CWD.
| headers: { | ||
| Authorization: `Bearer ${this.apiKey}`, | ||
| Accept: 'application/json', | ||
| ...cuaVersionHeaders('computer', __CUA_VERSION__), |
Contributor
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "1) Find __CUA_VERSION__ usages in the computer package"
rg -n --type=ts --type=tsx '__CUA_VERSION__' libs/typescript/computer
echo
echo "2) Check where __CUA_VERSION__ is defined/injected for build and test configs"
fd 'tsdown.config.ts|vite.config.ts|vitest.config.ts|package.json|tsconfig.json|tsconfig.*.json' libs/typescript/computer -t f \
| xargs -I{} sh -c 'echo "\n--- {} ---"; rg -n "__CUA_VERSION__|define" "{}" || true'
echo
echo "3) Compare with workspace-wide define patterns"
rg -n '__CUA_VERSION__|define' -g '**/tsdown.config.ts' -g '**/vite.config.ts' -g '**/vitest.config.ts' 2>/dev/null || echo "No workspace-wide matches found"Repository: trycua/cua
Length of output: 153
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "1) Find __CUA_VERSION__ usages in the computer package"
rg -n '__CUA_VERSION__' libs/typescript/computer --type-list | grep -i ts || true
rg -n '__CUA_VERSION__' libs/typescript/computer
echo
echo "2) Check where __CUA_VERSION__ is defined/injected for build and test configs"
find libs/typescript/computer -type f \( -name 'tsdown.config.ts' -o -name 'vite.config.ts' -o -name 'vitest.config.ts' -o -name 'package.json' -o -name 'tsconfig.json' \) | head -20
echo
echo "3) Search for __CUA_VERSION__ define patterns"
rg '__CUA_VERSION__' --type ts libs/typescript/computer
echo
echo "4) Look for define statements in config files"
rg 'define.*__CUA_VERSION__|__CUA_VERSION__.*define' -A 2 -B 2Repository: trycua/cua
Length of output: 1443
🏁 Script executed:
#!/bin/bash
echo "=== tsdown.config.ts ==="
cat -n libs/typescript/computer/tsdown.config.ts
echo
echo "=== vitest.config.ts ==="
cat -n libs/typescript/computer/vitest.config.ts
echo
echo "=== Check globals.d.ts ==="
cat -n libs/typescript/computer/src/globals.d.ts
echo
echo "=== Check package.json for scripts ==="
cat -n libs/typescript/computer/package.json | head -40Repository: trycua/cua
Length of output: 2318
🏁 Script executed:
#!/bin/bash
echo "=== Find test files ==="
find libs/typescript/computer/tests -type f -name '*.ts' 2>/dev/null | head -20
echo
echo "=== Search for imports of cloud provider in tests ==="
grep -r 'cloud' libs/typescript/computer/tests --include='*.ts' 2>/dev/null || echo "No matches"
echo
echo "=== Check setup.ts ==="
if [ -f "libs/typescript/computer/tests/setup.ts" ]; then
cat -n libs/typescript/computer/tests/setup.ts
else
echo "setup.ts not found"
fi
echo
echo "=== Check if cloud.ts is imported from index.ts ==="
rg 'export.*cloud|from.*cloud' libs/typescript/computer/src/index.tsRepository: trycua/cua
Length of output: 938
🏁 Script executed:
#!/bin/bash
echo "=== cloud.test.ts ==="
cat -n libs/typescript/computer/tests/computer/cloud.test.ts
echo
echo "=== Check src/index.ts for cloud export ==="
cat -n libs/typescript/computer/src/index.tsRepository: trycua/cua
Length of output: 813
🏁 Script executed:
#!/bin/bash
echo "=== Check src/computer/index.ts ==="
cat -n libs/typescript/computer/src/computer/index.ts
echo
echo "=== Check src/computer.ts if it exists ==="
if [ -f "libs/typescript/computer/src/computer.ts" ]; then
cat -n libs/typescript/computer/src/computer.ts
else
echo "Not found"
fi
echo
echo "=== Check directory structure of src/computer ==="
find libs/typescript/computer/src/computer -type f -name '*.ts' | sortRepository: trycua/cua
Length of output: 524
🏁 Script executed:
#!/bin/bash
echo "=== Check src/computer/providers/index.ts ==="
cat -n libs/typescript/computer/src/computer/providers/index.ts
echo
echo "=== Check if cloud.test.ts instantiation triggers cloud.ts module load ==="
echo "Looking at CloudComputer and how it instantiates with cloud provider..."
grep -n 'CloudComputer' libs/typescript/computer/src/computer/providers/*.ts | head -20
echo
echo "=== Check around line 67 of cloud.ts with context ==="
sed -n '50,80p' libs/typescript/computer/src/computer/providers/cloud.ts | cat -nRepository: trycua/cua
Length of output: 1871
🏁 Script executed:
#!/bin/bash
echo "=== Full cloud.ts file to check module-level code ==="
cat -n libs/typescript/computer/src/computer/providers/cloud.tsRepository: trycua/cua
Length of output: 6313
Add guard for __CUA_VERSION__ to prevent runtime errors outside build-injected contexts.
Line 67 accesses __CUA_VERSION__ inside the fetchAndCacheHost() method. While vitest does not inject this constant (only the build step does via tsdown.config.ts), the method won't be called by the current test suite. However, if run() is executed in any test or non-build runtime context, the direct access will throw a ReferenceError. Use a typeof check with a fallback:
Proposed fix
- ...cuaVersionHeaders('computer', __CUA_VERSION__),
+ ...cuaVersionHeaders(
+ 'computer',
+ typeof __CUA_VERSION__ === 'string' ? __CUA_VERSION__ : ''
+ ),📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| ...cuaVersionHeaders('computer', __CUA_VERSION__), | |
| ...cuaVersionHeaders( | |
| 'computer', | |
| typeof __CUA_VERSION__ === 'string' ? __CUA_VERSION__ : '' | |
| ), |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@libs/typescript/computer/src/computer/providers/cloud.ts` at line 67,
fetchAndCacheHost currently references the build-injected constant
__CUA_VERSION__ directly when calling cuaVersionHeaders('computer',
__CUA_VERSION__), which can throw a ReferenceError outside build contexts (e.g.,
tests). Change the call to guard against missing global by using a typeof check
and a fallback (e.g., typeof __CUA_VERSION__ !== 'undefined' ? __CUA_VERSION__ :
'' or undefined) so cuaVersionHeaders receives a safe value; update the
invocation inside fetchAndCacheHost to use that guarded expression.
| import { readFileSync } from 'node:fs'; | ||
| import { defineConfig } from 'tsdown'; | ||
|
|
||
| const pkg = JSON.parse(readFileSync('./package.json', 'utf-8')); |
Contributor
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
cat -n libs/typescript/computer/tsdown.config.tsRepository: trycua/cua
Length of output: 536
🏁 Script executed:
# Find other similar patterns mentioned in the review (agent config reference)
find . -name "*.config.ts" -type f | head -20Repository: trycua/cua
Length of output: 373
🏁 Script executed:
# Check if there's an agent config file that was similarly fixed
rg "readFileSync\(\s*['\"]\./" --type ts -A 2 -B 2Repository: trycua/cua
Length of output: 1421
🏁 Script executed:
# Check if there are package.json files at each of these directory levels
find libs/typescript -maxdepth 2 -name "package.json" | sortRepository: trycua/cua
Length of output: 266
🏁 Script executed:
# Check for root package.json
ls -la package.json 2>/dev/null && echo "Root package.json exists" || echo "No root package.json"Repository: trycua/cua
Length of output: 139
🏁 Script executed:
# Check how tsdown is invoked - look at build scripts
rg "tsdown" package.jsonRepository: trycua/cua
Length of output: 36
🏁 Script executed:
# Check where config files are located relative to their package.json
for config in libs/typescript/agent/tsdown.config.ts libs/typescript/computer/tsdown.config.ts libs/typescript/core/tsdown.config.ts; do
dir=$(dirname "$config")
echo "Config: $config"
echo " Directory: $dir"
if [ -f "$dir/package.json" ]; then
echo " Has local package.json: YES"
else
echo " Has local package.json: NO"
fi
doneRepository: trycua/cua
Length of output: 393
🏁 Script executed:
# Check the contents of the computer package.json to see if it has a version
head -20 libs/typescript/computer/package.jsonRepository: trycua/cua
Length of output: 589
🏁 Script executed:
# Verify the fix works with readFileSync - check Node.js documentation pattern
# Create a test to see if readFileSync accepts URL in this context
node <<'EOF'
import { readFileSync } from 'node:fs';
// Check what readFileSync expects
console.log("readFileSync signature supports:");
console.log("- String path");
console.log("- Buffer path");
console.log("- URL path (in Node.js 18.17+)");
// Test the import.meta.url pattern with a file in this repo
const testPath = new URL('./package.json', import.meta.url);
console.log("\nTest URL construction:");
console.log("Type:", typeof testPath);
console.log("Value:", testPath.toString());
// Note: readFileSync with URL should work in modern Node.js
EOFRepository: trycua/cua
Length of output: 228
🏁 Script executed:
# Check Node.js version requirements in the project
rg "engines.*node" package.jsonRepository: trycua/cua
Length of output: 36
🏁 Script executed:
# Check root package.json for Node version requirements
cat package.json | head -30Repository: trycua/cua
Length of output: 381
🏁 Script executed:
# Check if import.meta.url is used elsewhere in the codebase
rg "import\.meta\.url" --type ts | head -5Repository: trycua/cua
Length of output: 325
🏁 Script executed:
# Check the cua-cli example more closely to see the exact pattern used
cat -n libs/typescript/cua-cli/src/http.ts | grep -A 2 -B 2 "readFileSync"Repository: trycua/cua
Length of output: 323
🏁 Script executed:
# Check how tsdown is actually invoked in build scripts
rg "tsdown" --type json -A 1 -B 1 | head -40Repository: trycua/cua
Length of output: 1863
🏁 Script executed:
# Check if there's a root tsdown or build that could be run from different directories
rg "tsdown" --type sh -A 1 -B 1Repository: trycua/cua
Length of output: 36
🏁 Script executed:
# Look for CI configuration that might invoke builds from different directories
find . -name "*.yml" -o -name "*.yaml" | xargs grep -l "tsdown\|build" 2>/dev/null | head -5Repository: trycua/cua
Length of output: 252
🏁 Script executed:
# Check the CD workflow for TypeScript/CLI
cat ./.github/workflows/cd-ts-cli.yml | head -50Repository: trycua/cua
Length of output: 1418
🏁 Script executed:
# Also check if there's a root-level build that might call these configs
find . -maxdepth 2 -name "tsdown.config.ts" -exec dirname {} \; | while read dir; do
echo "=== $dir ==="
if grep -q "build\|tsdown" "$dir/package.json" 2>/dev/null; then
echo "Has build/tsdown in package.json"
grep -o '"[^"]*tsdown[^"]*"' "$dir/package.json" | head -3
fi
doneRepository: trycua/cua
Length of output: 36
Make manifest lookup CWD-independent.
This config uses ./package.json (relative path), which is CWD-dependent. If the build starts from a different directory—such as the monorepo root—it will fail or load the wrong version. The same pattern is already correctly implemented elsewhere in the codebase (libs/typescript/cua-cli/src/http.ts).
🔧 Suggested fix
-const pkg = JSON.parse(readFileSync('./package.json', 'utf-8'));
+const pkg = JSON.parse(readFileSync(new URL('./package.json', import.meta.url), 'utf-8'));📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| const pkg = JSON.parse(readFileSync('./package.json', 'utf-8')); | |
| const pkg = JSON.parse(readFileSync(new URL('./package.json', import.meta.url), 'utf-8')); |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@libs/typescript/computer/tsdown.config.ts` at line 4, The code in
tsdown.config.ts reads package.json via a CWD-relative path (const pkg =
JSON.parse(readFileSync('./package.json', 'utf-8'))), which is brittle; change
it to compute the package.json path relative to this module so it is
CWD-independent—e.g., replace the readFileSync('./package.json', ...) call with
reading via a URL resolved from import.meta.url (or the runtime-equivalent) such
as readFileSync(new URL('../package.json', import.meta.url), 'utf-8') and keep
assigning to pkg; ensure the change targets the const pkg assignment in
tsdown.config.ts so package.json is loaded relative to the config file rather
than the current working directory.
| import { readFileSync } from 'node:fs'; | ||
| import { defineConfig } from 'tsdown'; | ||
|
|
||
| const pkg = JSON.parse(readFileSync('./package.json', 'utf-8')); |
Contributor
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# First, let's check the file content and surrounding context
head -20 libs/typescript/core/tsdown.config.tsRepository: trycua/cua
Length of output: 383
🏁 Script executed:
# Check if this is ES modules (import.meta.url support depends on module type)
cat libs/typescript/core/tsdown.config.ts | head -30Repository: trycua/cua
Length of output: 383
🏁 Script executed:
# Look for package.json at the root to understand monorepo structure
git ls-files | grep -E "package\.json$" | head -20Repository: trycua/cua
Length of output: 364
🏁 Script executed:
# Check other tsdown.config files for comparison
fd "tsdown.config" --type fRepository: trycua/cua
Length of output: 216
🏁 Script executed:
# Check the project's Node version and module configuration
cat package.json | grep -A 5 '"type"'Repository: trycua/cua
Length of output: 36
🏁 Script executed:
# Check tsconfig or other configs to understand module system
fd "tsconfig\|\.js\|\.ts" -t f -x grep -l "import.meta" {} \; | head -10Repository: trycua/cua
Length of output: 36
🏁 Script executed:
# Check the package.json in the same directory as the config file
cat libs/typescript/core/package.json | head -20Repository: trycua/cua
Length of output: 570
🏁 Script executed:
# Check if other tsdown configs use the same pattern
for f in $(fd "tsdown.config" --type f); do
echo "=== $f ==="
grep "readFileSync" "$f"
doneRepository: trycua/cua
Length of output: 668
🏁 Script executed:
# Verify Node.js version requirement to ensure import.meta.url support
cat package.json | jq '.engines // .devDependencies | select(. != null)'Repository: trycua/cua
Length of output: 80
🏁 Script executed:
# Check if there are any build scripts that invoke tsdown and where they run from
grep -r "tsdown" package.json libs/*/package.json 2>/dev/null | grep -v ".pnp"Repository: trycua/cua
Length of output: 36
🏁 Script executed:
# Check how tsdown configs are invoked - look for build scripts
find . -maxdepth 2 -name "package.json" -exec grep -l "tsdown" {} \;Repository: trycua/cua
Length of output: 36
🏁 Script executed:
# Check if there are workspace definitions that might run tsdown from root
cat package.json | jq '.workspaces // .pnpm // empty'Repository: trycua/cua
Length of output: 36
🏁 Script executed:
# Verify if readFileSync accepts URL objects in the Node version being used
grep -E "node|engines" package.json | head -5Repository: trycua/cua
Length of output: 36
🏁 Script executed:
# Check the actual import statement - is import.meta available?
node --versionRepository: trycua/cua
Length of output: 61
🏁 Script executed:
# Look for any actual build invocations to understand execution context
grep -r "tsdown\|build" package.json libs/typescript/*/package.json 2>/dev/null | grep -E "scripts|\"(build|tsdown)\""Repository: trycua/cua
Length of output: 539
🏁 Script executed:
# Check if there's a root-level build script that might invoke tsdown from the root
cat package.json | jq '.scripts // empty'Repository: trycua/cua
Length of output: 225
🏁 Script executed:
# Look for monorepo configuration (pnpm workspaces, npm workspaces, lerna, etc.)
ls -la | grep -E "pnpm-workspace|lerna|turbo|nx"
cat pnpm-workspace.yaml 2>/dev/null || echo "No pnpm-workspace.yaml"Repository: trycua/cua
Length of output: 76
🏁 Script executed:
# Check if there's a build workflow that might run from root
find . -maxdepth 2 -type f \( -name ".github" -o -name "*.yml" -o -name "*.yaml" \) -exec grep -l "tsdown\|build" {} \; 2>/dev/nullRepository: trycua/cua
Length of output: 75
🏁 Script executed:
# Verify readFileSync can accept URL objects in Node 24
node --eval "import('fs').then(fs => console.log(typeof fs.readFileSync))"Repository: trycua/cua
Length of output: 62
Use file-relative manifest resolution to avoid wrong version injection.
./package.json is CWD-dependent and will read the wrong manifest if tsdown is invoked from the repository root or a parent directory—a common pattern in monorepo build systems. This applies to all four tsdown configs in the workspace.
🔧 Suggested fix
-const pkg = JSON.parse(readFileSync('./package.json', 'utf-8'));
+const pkg = JSON.parse(readFileSync(new URL('./package.json', import.meta.url), 'utf-8'));Apply this fix to:
libs/typescript/core/tsdown.config.tslibs/typescript/agent/tsdown.config.tslibs/typescript/computer/tsdown.config.tslibs/typescript/playground/tsdown.config.ts
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| const pkg = JSON.parse(readFileSync('./package.json', 'utf-8')); | |
| const pkg = JSON.parse(readFileSync(new URL('./package.json', import.meta.url), 'utf-8')); |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@libs/typescript/core/tsdown.config.ts` at line 4, The current pkg load uses a
CWD-dependent path (const pkg = JSON.parse(readFileSync('./package.json',
'utf-8'));), which can pick up the wrong manifest in monorepos—change the
readFileSync call in each tsdown.config.ts to resolve package.json relative to
the config file (e.g., use path.resolve(__dirname, '../package.json') or
path.join(__dirname, 'package.json') as appropriate) before JSON.parse so pkg is
always loaded from the config's package.json; update the import/require usage to
include Node's path and ensure the same change is applied in the four
tsdown.config.ts files (core, agent, computer, playground).
Contributor
📦 Publishable packages changed
Add |
Contributor
📦 Publishable packages changed
Add |
Contributor
📦 Publishable packages changed
Add |
mdean808
added
release:pypi/cli
Contributor
📦 Publishable packages changed
|
8 similar comments
Contributor
📦 Publishable packages changed
|
Contributor
📦 Publishable packages changed
|
Contributor
📦 Publishable packages changed
|
Contributor
📦 Publishable packages changed
|
Contributor
📦 Publishable packages changed
|
Contributor
📦 Publishable packages changed
|
Contributor
📦 Publishable packages changed
|
Contributor
📦 Publishable packages changed
|
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Summary by CodeRabbit
New Features
setup_configparameter to interactive task runner for enhanced configuration options.Documentation
Chores