mirror of
https://github.com/ComposioHQ/composio.git
synced 2026-09-22 11:46:35 +08:00
@composio/cli@0.4.2-beta.391
1323 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 jkomyno
|
884951b002 |
test(cli): guard the tokenizer and companion entries at startup
The startup-imports test now forbids js-tiktoken and both companion entry modules, matching the executable graph check in scripts/_shared.ts. |
||
|
jkomyno
|
73f710b5cf |
fix(cli): repair a companion's own files before importing it
Bun keeps a failed or already-loaded import in its module registry, so importing a companion again after a repair can still see the missing dependency or the old module. Repair now runs before the single import, and only when the requested companion's wrapper or its import graph is missing, so unrelated missing companions still cannot block it. Claude-Session: https://claude.ai/code/session_01MTb47vexN35pLGsSZwBmrJ |
||
|
jkomyno
|
19f7f2a002 |
fix(cli): scope companion repair and keep unmeasured large output stored
- Import an in-process companion before checking the rest of the set, so a missing unrelated companion cannot fail generate or run through an offline repair. Repair runs only when the requested module fails to load. - Check each companion's required exports, so a file left by another release fails with a typed reinstall error instead of calling a missing export. - When the tokenizer cannot load, store any response past the byte pre-filter. The four-bytes-per-token estimate can undercount, so it no longer keeps a response inline. - Bundle the executable graph check with the release build's env inlining, defines, NODE_ENV and syntax minification. Claude-Session: https://claude.ai/code/session_01MTb47vexN35pLGsSZwBmrJ |
||
|
jkomyno
|
af90b83c01 |
Merge branch 'next' into claude/cli-startup-bundle-diet-c7xicz
Resolve the generate and run loaders in favor of the generation companion, drop the entry modules it supersedes, and let the startup-imports test allow src/generation/errors.ts as the binary build guard does. Claude-Session: https://claude.ai/code/session_01MTb47vexN35pLGsSZwBmrJ |
||
|
jkomyno
|
c9c3e49fee |
test(cli): wait for the hung host command before advancing the clock
The hung-native-host test forked setup, yielded once, then advanced the TestClock by two minutes. Setup does real file I/O before it reaches the host command, so on a slow CI worker the timeout was not yet armed when the clock moved; the sleep then waited forever and the test failed on vitest's own 15s limit. It flaked on next-based branches today, not only this one. The hanging runner now opens a latch when setup reaches it, and the test advances the clock only after that. Claude-Session: https://claude.ai/code/session_01MTb47vexN35pLGsSZwBmrJ |
||
|
jkomyno
|
c0053d7eeb |
test(cli): guard the startup path against eager compiler imports
A static import of typescript or src/generation anywhere on the command tree silently restores ~165ms of module evaluation to every invocation, and nothing failed. The test loads the command tree in a fresh Bun process and asserts, via the module registry, that neither the compiler nor the generation pipeline nor the run source transforms were evaluated. Verified it fails on a stray static import. Claude-Session: https://claude.ai/code/session_01MTb47vexN35pLGsSZwBmrJ |
||
|
jkomyno
|
6b0db59c30 |
refactor(cli): load each generation pipeline through one entry module
The generate handlers assembled their pipeline from three or four dynamic imports and repackaged the results by hand. Each pipeline now has an index module that re-exports what the handler needs, so the deferred load is a single import and the boundary the handler crosses is named. Claude-Session: https://claude.ai/code/session_01MTb47vexN35pLGsSZwBmrJ |
||
|
jkomyno
|
33e54a76a7 |
refactor(cli): import run source transforms through the src alias
Every other deferred import in the CLI spells its target with the src alias; the run command was the one relative specifier. Claude-Session: https://claude.ai/code/session_01MTb47vexN35pLGsSZwBmrJ |
||
|
jkomyno
|
4ce75c9245 |
fix(cli): keep large executes working when the encoder companion fails to load
A large execute measured its output after the tool call had already succeeded, so a missing encoder companion whose repair download failed turned a successful call into a failed command. Fall back to a byte-based token estimate instead. Load companion modules with Effect.tryPromise so an unloadable file is a typed RunCompanionRepairError rather than a defect, and add the two companions as tsdown entries so the dist build can resolve them. The executable graph check listed @composio/core's root entry with a pattern that could never match Bun's relative module paths. The root entry is still bundled behind the file-upload dynamic import, so drop that entry and correct the constants comment. |
||
|
DakshM on Exe (exe.dev)
|
0a1464d5e8 |
perf(cli): move the compiler and tokenizer out of the executable
`composio --version` goes from 288ms to 199ms, peak RSS from 97.8MB to 77.3MB, and the executable from 85.9MB to 79.7MB. Every command benefits. A compiled Bun binary parses its whole embedded bundle before the first line of JavaScript runs, and #4468 had already made sure the TypeScript compiler and the tokenizer rank table were never *evaluated* unless `generate`, `run`, or a large `execute` response needed them. They were still *parsed* on every start: the compiler alone was 44% of the executable's JavaScript and the o200k rank table another 28%, so `--version` spent ~75ms reading code it could never call. Both now ship as companion modules next to the executable, through the mechanism `composio run` already uses for its own runtime helpers: - `generation-runtime.mjs` carries `src/generation/*`, the `composio run` source rewrites, `typescript`, `@composio/ts-builders` and `openapi-typescript`. `generate ts`, `generate py` and `run` load it with `loadInstalledCompanionModule`; from a source checkout the loader resolves the `.ts` next to `run-companion-modules.ts` instead, so tests and `bun run src/bin.ts` need no build step. - `execute-output-encoder-runtime.mjs` carries `js-tiktoken/lite` and the rank table. `execute` loads it only once a response exceeds the 10KB byte pre-filter. A companion bundles its own copy of `effect`, and a fiber cannot run primitives built by another copy of the runtime, so nothing Effect-shaped crosses the boundary: the generation companion exposes plain functions and promises, runs its pipelines on its own runtime, and returns failures as values that `src/generation/errors.ts` rebuilds as the CLI's own error classes, stack included. Generated output is byte-identical to #4468 for `generate ts`, `generate ts --transpiled` and `generate py`. Both modules join `RUN_COMPANION_MODULE_BASENAMES`, so the build, release packaging, install verification, `upgrade` and the self-repair download pick them up unchanged. The three hand-maintained uninstall lists and the upgrade E2E fixture gain the two file names. Two smaller startup costs go with it: - `src/constants.ts` imported `constants` from `@composio/core`'s root entry for two strings and two URLs, which evaluated the whole SDK at startup (~25ms of module-scope work, mostly zod schemas). The four values are spelled out and pinned to core's by a test. - `tool-file-uploads.ts` imported three core helpers at module scope that only a file upload reaches; they are imported on that path now. The binary build gains a guard: after bundling the companions it bundles `src/bin.ts` once more unminified and fails if the executable's graph reaches `typescript`, `js-tiktoken`, core's root entry, `src/generation/*` or a companion entry. Without it a stray static import would put the compiler back into the executable with nothing to notice. Building also surfaced that `assertBundledRuntimeFiles` blanked string literals to same-length runs of spaces, which made the import patterns' `^\s*` backtrack quadratically across the compiler's multi-megabyte embedded lib strings and stalled the build for over ten minutes. String bodies are dropped now. (The check itself has never matched a specifier, since the specifiers it looks for are the string literals it removes; that is left as it was.) Measured on the pinned toolchain, Bun 1.4.1+4661e494f, linux-x64, best of 15, telemetry disabled, both binaries built in the same session: composio --version 288ms -> 199ms tools execute --help 287ms -> 202ms peak RSS 97.8MB -> 77.3MB executable 85.9MB -> 79.7MB executable JavaScript 8.3MB -> 2.1MB (minified) The `execute` tail after `execute.tool_call.end` is unchanged for responses under 10KB (~10ms) and ~20ms slower above it (351 -> 374ms), which is the on-demand parse of the 2.2MB encoder companion. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Wx9gEjuiHux2weiHjdNcDs |
||
|
Claude
|
3b18bf38eb |
perf(cli): defer the TypeScript compiler and generation pipeline
`composio --version` drops from 622ms to 408ms, and eager module evaluation
from 363.8ms to 130.0ms, measured on the pinned toolchain (Bun
1.4.1+4661e494f, linux-x64, best of 7, analytics disabled).
`commands/index.ts` builds the root command tree from every `.cmd.ts` module,
so evaluating any one command evaluated all of them. Two of those modules
reached the TypeScript compiler and the code generation pipeline, which
nothing but `composio generate` and `composio run` ever calls:
155.8ms -> 8.0ms commands/run.cmd
63.5ms -> 2.5ms commands/generate
The command tree itself is untouched. `Command.withHandler(input => Effect)`
already runs lazily, so moving these imports inside the handler bodies is
enough. Specs, flags, descriptions, subcommand wiring and `root-help.ts`
introspection all still resolve eagerly, which is why parsing, help rendering
and "did you mean" suggestions cannot shift.
run.cmd.ts was the CLI's only consumer of `import ts from 'typescript'`,
through three source rewrites that `composio run` applies to a user script.
Those move to `run-source-transforms.ts`, which the handler imports
dynamically. The test suite imports them from the new path.
ts.generate.cmd.ts and py.generate.cmd.ts pulled `src/generation/*` at module
scope. Both now resolve it inside the handler, immediately before the first
use.
A rejected import of a module bundled into this binary is an impossible
invariant rather than a recoverable failure, so these use `Effect.promise`
rather than `Effect.tryPromise`. The module registry memoizes each import, so
repeat calls within one run cost nothing.
Behavior is unchanged, checked rather than assumed. Eleven invocations,
covering `--help` at root and for generate, generate ts, generate py, run,
tools and execute, plus `version`, `--version`, an unknown command and an
unknown flag, produce byte-identical stdout, stderr and exit codes before and
after.
Verified with typecheck (src and test), oxlint, validate:boundaries,
validate:skills, and the full package suite: 1326 passed, 1 skipped.
`test/src/cli-main.test.ts` times out in this container and does so identically
on the parent commit (25.6s and 25.2s there, 24.5s and 24.3s here) because it
spawns the CLI from source against a 15s timeout. Not caused by this change.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EzaE7oGVgziJ5nRvBhcci2
|
||
|
jkomyno
|
9895726510 |
docs(cli): describe special-token literals as counted special tokens
encode(json, 'all') turns each literal into one special token rather than counting its characters as text, so say that in the comment and the test name. |
||
|
Claude
|
4f11a440e9 |
fix(cli): stop tiktoken special-token literals from failing execute
`Tiktoken.encode` signs as `encode(text, allowedSpecial = [],
disallowedSpecial = "all")`. The CLI passed only the text, so every special
token was disallowed and the call threw on any response containing the
literal `<|endoftext|>` or `<|endofprompt|>`. A 66-byte payload is enough.
Reading a README that documents a tokenizer hits it.
The throw landed in `prepareExecuteOutput`, after `spinner.stop('Execution
successful')` had already printed. So the tool had run, its side effects had
happened, and the CLI still exited 1 with nothing on stdout and no session
history entry.
Here the encoder is only a length gauge for the inline-versus-file decision,
so those literals are ordinary characters. Passing `allowedSpecial: 'all'`
counts them instead of rejecting the payload. Token counts are unchanged on
text that contains no special tokens.
The preceding commit's byte-length pre-filter hid this below 10KB by
skipping the encoder. Larger responses still reached it, and both call sites
were affected: the threshold check and the `tokenCount` reported for a
stored file. Both now go through one `countOutputTokens` helper.
The regression test drives the real command with a response holding both
literals, sized past the inline threshold so the count is actually computed.
Verified it fails without the fix, with the original error:
Error: The text contains a special token that is not allowed: <|endoftext|>
Verified with typecheck (src and test), oxlint, validate:boundaries, and the
tools.execute and run command suites, now 90 tests.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EzaE7oGVgziJ5nRvBhcci2
|
||
|
jkomyno
|
cbcdecf3a9 |
perf(cli): skip the tokenizer for run-origin executes and count tokens once
Check the invocation origin before building the tokenizer, since composio run always prints inline, and pass the token count from the threshold check into the stored-output summary instead of encoding the payload twice. Add a test for a response past the byte pre-filter but under the token threshold, and drop the unused ts-morph dependency. |
||
|
Claude
|
ebe8bb780f |
perf(cli): cut 221ms and 44MB RSS off every CLI invocation
A compiled Bun binary parses its whole embedded module graph before the
first line of JS runs, so bundled-but-unused code is paid for on every
invocation. Verified: a binary that bundles everything but evaluates only
console.log still costs ~235ms, against 15ms for a hello-world build.
Most of this bundle was code `composio execute` never reaches.
Measured on the pinned toolchain (Bun 1.4.1+4661e494f, linux-x64,
best of 7, analytics disabled):
composio --version 970ms -> 749ms (-221ms)
peak RSS 175.8MB -> 132.2MB (-43.6MB)
compiled binary 96MB -> 86MB
bundle 31.24MB -> 15.84MB
Four changes.
run.cmd.ts imported `ts` from ts-morph, which vendors its own copy of the
TypeScript compiler, so the binary carried two of them. The file uses only
createSourceFile, forEachChild, ScriptTarget, ScriptKind and five isX
guards, all available in the typescript copy that
src/generation/typescript/* already pulls in. Sharing one compiler also
means commands/generate and commands/run.cmd no longer evaluate a compiler
each.
js-tiktoken's main entry statically inlines all six BPE rank tables (gpt2,
r50k, p50k, p50k_edit, cl100k, o200k) as string literals; the CLI only ever
uses o200k, via encodingForModel('gpt-4o'). The lite build with that single
table produces identical token-id streams.
prepareExecuteOutput built the o200k rank table on every successful
execute, purely to compare the response against a 10k-token threshold.
Constructing it measured ~390ms in a compiled binary on the pinned
toolchain (390.1, 367.1, 418.6ms across three runs), against ~4ms to
encode a 7.5KB payload once the table exists. A BPE token always covers at
least one UTF-8 byte, so a payload of at most THRESHOLD bytes can never
exceed THRESHOLD tokens; checking byte length first reaches the same
decision without the tokenizer.
That ~390ms is construction cost measured in isolation, not an end-to-end
delta on a real `composio execute`. No credentialed run was available to
measure the whole command before and after, so treat it as the size of the
work removed from the success path rather than a verified wall-clock
saving. `COMPOSIO_PERF_DEBUG=1` reports the gap between
`execute.tool_call.end` and exit for anyone able to run it for real.
ToolsExecutorLive resolved a client through clientSingleton.get()
unconditionally, walking the project context off disk, then discarded it
because every caller on the remote-execute path passes one in.
Three behavioral deltas, none of them the tokenization result or the
inline/file decision:
1. Tiktoken.encode() throws on the literals <|endoftext|> and
<|endofprompt|> appearing anywhere in the response, at any size (a
66-byte payload reproduces it). That throw landed after
"Execution successful" had printed, so the tool ran and the CLI still
exited 1 with nothing on stdout. Responses at or under 10KB no longer
reach encode(), so they now succeed. Larger responses still hit it;
the real fix is passing allowedSpecial 'all' and is not in this commit.
2. TypeScript 6.0.2 (ts-morph's vendored copy) to 6.0.3. Differential
tested: the three real parse helpers over 20 sources covering TSX,
decorators, `using`, `satisfies`, import attributes, optional-chained
calls and unicode gave identical output on all 60 comparisons.
3. Under COMPOSIO_LOG_LEVEL=Debug, ProjectContext's "resolved from ..."
debug lines no longer appear on the remote-execute path. The local-tool
path still calls get() and is unchanged.
Verified with typecheck:src, oxlint, validate:boundaries, the
tools.execute and run command suites (89 tests), and differential tests of
both tokenizers and both TypeScript versions.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EzaE7oGVgziJ5nRvBhcci2
|
||
|
Alberto Schiabel
|
efe6d89864 |
chore(cli): refresh baked toolkit slugs (#4477)
## Summary Automated refresh of the toolkit slugs the CLI knows without asking the API, generated by `ts/packages/cli/scripts/generate-toolkit-slugs.ts`. Toolkits added since the last refresh currently cost users one toolkit-list fetch (~2 s) the first time they run one of that toolkit's tools. Merging this makes them free. The generator refuses to write a list that is short, malformed, or missing staple toolkits, so a bad fetch opens no PR at all. |
||
|
jkomyno
|
3ab81b3373 | chore(cli): refresh baked toolkit slugs | ||
|
jkomyno
|
8bb1d29950 |
fix(core): raise tool not found only on 404/400
getRawComposioToolBySlug relabelled every client error, including an invalid API key (401), as ComposioToolNotFoundError. Map only 404/400 to not-found and wrap the rest in a new ComposioToolFetchError that keeps the client error as cause. Toolkits.getToolkitBySlug compared against the OpenAI APIError class, so its not-found branch never fired; import the Composio client class instead. Python mirrors the mapping: an unknown slug raises ToolNotFoundError (now a NotFoundError), anything else propagates the composio_client error unchanged. PRDE-1613 Claude-Session: https://claude.ai/code/session_017HtbhwMAKcfebo8HyXWa5s |
||
|
Alberto Schiabel
|
2367b80d9d |
chore(ci): enforce agent guidance validators in CI (#4447)
This PR: - Add `.github/workflows/agent-substrate.yml` running `pnpm validate:agent-skills` and `pnpm validate:skill-routing` on every push and pull request; both validators previously ran in no CI workflow - No path filters on the trigger: the stale-guidance walk scans every text file in the repo, so any change can affect the result (PR runs restore caches but only `next` pushes save them, per the `setup-node-pnpm-bun` guidance) - Skip `vendor/` directories in the `validate:agent-skills` stale-guidance walk, which was failing on read-only third-party snapshots mentioning other tools' rule conventions - Extend the validator's command scan to `CONTRIBUTING.md` (with a `pnpm dlx` exemption), so its documented commands are checked against `package.json`, `python/Makefile`, and `python/noxfile.py` like the rest of the guidance - Point the routing-test header, root `AGENTS.md`, and `skill-maintenance` reference docs at the new workflow, and add a "Working with AI Coding Agents" section to `CONTRIBUTING.md` covering the inherited agent setup, the two checks, and the routing-probe requirement for skill edits ## Context These two validators are the only checks keeping repo-level agent guidance honest: command names mentioned in guidance are verified against `package.json`, `python/Makefile`, and `python/noxfile.py`, and routing probes assert each skill stays the unique top match for its representative task. Until now nothing enforced either one, and the stale-guidance walk was already red on vendored trees — a failure no guidance owner could fix, which trains people to ignore the check. This makes both checks blocking everywhere they can bite. ## Verification - `pnpm validate:agent-skills` — 19 skills, green, now including `CONTRIBUTING.md` commands - `pnpm validate:skill-routing` — 19 probes over 19 skills, green - Workflow YAML parsed; oxlint and prettier clean on touched files - `Agent Substrate` workflow ran green on this PR (42s) before the trigger change and re-runs on every push |
||
|
Alberto Schiabel
|
d1bc94c580 |
test(ts/e2e): exercise core tool execution under Deno (#4418)
This PR: - builds on top of https://github.com/ComposioHQ/composio/pull/3901 - adds a second Deno e2e suite, `@e2e-tests/deno-tool-execution`, that drives the runtime instead of the import surface: session creation over `fetch`, custom-tool registration, Zod validation/defaults/failures, and in-process local tool execution - mirrors the node `custom-tools` suite trimmed to its local-execution half; remote coverage (tool chaining, weathermap) stays node-only - imports the workspace's built dist via a relative path: a version-less `npm:@composio/core` resolves from the registry (published pre-migration 0.18.1), ignoring the pnpm workspace symlink, so the direct path is what makes the suite test the Effect v4 build CI bakes into the image - keeps the only backend call to `composio.create()`; requires `COMPOSIO_API_KEY` (CI provides it, the runner passes it into the container) ## Context The existing `deno/esm-basic` suite stops at the import/export surface and, despite its `deno.jsonc` comment, resolves `npm:@composio/core` from the registry rather than the workspace — so nothing under Deno exercised the Effect v4 runtime. This suite closes that gap. A side observation for a follow-up: `esm-basic` has the same registry-resolution drift and tests the published package, contrary to its README. Validation: - full local Deno matrix passes against the staging backend: 22 tests / 2 suites (11 + 11), fixture markers `SESSION_CREATE_OK` through `ALL_OK` all observed - `pnpm --filter @e2e-tests/deno-tool-execution typecheck` and prettier clean - `pnpm-lock.yaml` updated for the new workspace importer Merge after #3901. |
||
|
Alberto Schiabel
|
0abc629f5d |
refactor(cli): migrate to Effect 4 (4.0.0-rc.112) (#3901)
Rebuilds the Effect v4 port on top of `next` at `effect@4.0.0-rc.112` (the newest release that clears the repository's 3-day `minimumReleaseAge` gate). The three v3-compatible preparation PRs (#4358, #4359, #4360) already landed on `next`, so this PR is now only the cutover. ## What changes - Pins `effect`, `@effect/platform-bun`, and `@effect/vitest` to exact `4.0.0-rc.112`; drops `@effect/cli`, `@effect/platform`, `@effect/platform-node`, and the `toml` override that existed only for `@effect/cli`. The `ts/vendor/effect` source oracle moves to the `effect@4.0.0-rc.112` release commit. - Services become `Context.Service` classes with explicit `Default` layers; `Either` becomes `Result`; `ParseResult` becomes `Schema.SchemaError`; platform modules come from `effect/FileSystem`, `effect/Path`, `effect/PlatformError`, `effect/unstable/process`, and `effect/unstable/http`. - The runner drives `Command.runWith` with v4's default help and error rendering. `CliError.ShowHelp` carries its own exit code, help for non-explicit invocations renders on stderr, and "Did you mean?" suggestions render. `command-introspection.ts` is gone: v4 renders the resolved command's help and the "missing value" tip itself. - `composio --version`, `composio -v`, and `composio version` print the same bare semver (`GlobalFlag.Version` is not enabled; the flag spellings are rewritten to the `version` command before parsing). - Root `--log-level` is a shared flag applied after the subcommand tree is attached, so `composio --log-level Debug <subcommand>` both parses and takes effect. - Every `Flag.boolean` carries an explicit default, because rc.112 makes boolean flags required when omitted. - A `Result` is not an `Effect` at runtime in rc.112 even though the type checker accepts `yield*` on it (the fiber dies with "Not a valid effect"); every `Result` is lifted with `Effect.fromResult`, and the skill/AGENTS guidance says so. - Every `ChildProcess.make` site passes `extendEnv: true`, because rc.112 no longer inherits the parent environment by default. - `--log-level` and `COMPOSIO_LOG_LEVEL` are exact-match on the `LogLevel` names (`All`, `Fatal`, `Error`, `Warn`, `Info`, `Debug`, `Trace`, `None`) with no case folding, per the earlier review decision; README updated. - Spawned children pass `extendEnv: true`, because rc.112's `ChildProcess` no longer inherits the parent environment by default. - ISO timestamps decode through `Schema.DateTimeUtcFromString`; `Schema.DateTimeUtc` is no longer a string codec in rc.112. - `ConfigProvider.fromEnv()` snapshots the environment at construction in v4, so providers that must observe later changes are built per read (`plugin-hint.ts`, `install.cmd.ts`, `config.ts`) and tests use a live-env provider helper. - `cli-keyring` and `json-schema-to-effect-schema` are ported alongside (the latter on `Schema.makeFilter`). - The `effect-v4` skill, the `cli-command` and `typescript-testing` references, `ts/packages/cli/AGENTS.md`, and the oxlint config are updated to the rc.112 reality. The skill's example checker (`.agents/skills/effect-v4/scripts/check-examples.mjs`, lifted from #3851) compiles every TypeScript block in the skill against the pinned packages. - The `js-yaml` overrides move to the 4.3.2 / 3.15.2 lines that GHSA-2883-xcg3-v3hh requires; `pnpm audit --prod` is clean apart from the already-ignored `extract-zip` advisory. ## Behaviour notes - `composio <unknown> --help` now prints the root help with exit 0 (v4's global `--help` handling); `composio <unknown>` without `--help` still fails with the unknown-subcommand error. ## Validation - `pnpm --filter @composio/cli typecheck` (src + test): 0 errors - `pnpm --filter @composio/cli test`: 127 files, 1325 tests pass, 1 skipped; `validate:boundaries` and `validate:skills` pass - `@composio/cli-keyring` and `@composio/json-schema-to-effect-schema` typecheck, test, and build pass - `pnpm validate:agent-skills` and `pnpm validate:skill-routing` pass (19 skills) - oxlint clean on `ts/packages/cli`, `cli-keyring`, `json-schema-to-effect-schema` - CLI bundle and standalone binary build; smoke-checked `version`, `--version`, `-v`, `--help`, unknown subcommand, unrecognized flag, missing flag value - Docker CLI e2e suites pass against an image built from this branch: `version`, `toolkits-list`, `toolkits-info`, `toolkits-search`, `setup-plugins`, `run`. `whoami` (needs an API key), `install` (needs a release dir), and `upgrade` (needs network) were not run. No changeset: `@composio/cli` is Changesets-ignored and the ported sibling packages are private. Human-facing notes are in `ts/packages/cli/CHANGELOG.md`. https://claude.ai/code/session_01AW7ZPhfZuni6PrCJ9X86DX |
||
|
Saransh Rana
|
a69f82d676 |
fix(sdk): run typedoc without a shell in generate-docs (SEC-899) (#4416)
## Summary
`ts/packages/core/scripts/generate-docs.ts` joined `npx typedoc` and
every discovered `src/models/*.ts` file name into one string and ran it
with `execSync`, so a model file whose name contains shell
metacharacters would execute as a command. The script runs in CI on
every push to `next` with a write-scoped app token
(`generate-sdk-docs.yml`). Reported by AppSecure as SEC-899 (command
injection via documentation generation).
Fixes SEC-899 (internal tracker).
## Changes
- Build the typedoc argument vector as an array (`buildTypeDocArgs`) and
run it with `execFileSync`, so no shell is involved.
- Skip model files whose names fall outside `[A-Za-z0-9_.-]` (with a
warning) in `discoverModelFiles`.
- Regression tests in `test/scripts/generate-docs.test.ts`:
metacharacter names are dropped, entry points stay separate arguments.
## Type of change
- [x] Bug fix
- [ ] New feature
- [ ] Refactor/Chore
- [ ] Documentation
- [ ] Breaking change
## How Has This Been Tested?
```
pnpm --filter @composio/core exec vitest run test/scripts/generate-docs.test.ts
Test Files 1 passed (1)
Tests 12 passed (12)
pnpm exec prettier --check ts/packages/core/scripts/generate-docs.ts ts/packages/core/test/scripts/generate-docs.test.ts
All matched files use Prettier code style!
```
Node 24.17.0 and pnpm 11.8.0 via mise.
## Screenshots (if applicable)
## Checklist
- [x] I have read the Code of Conduct and this PR adheres to it
- [x] I ran linters/tests locally and they passed
- [x] I updated documentation as needed
- [x] I added tests or explain why not applicable
- [x] I added a changeset if this change affects published packages (not
needed: `scripts/` is a build-time script, not part of the published
package)
## Additional context
The generated docs output is unchanged; only how typedoc is invoked
changes.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
---------
Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>
Co-authored-by: jkomyno <alberto@composio.dev>
|
||
|
Saransh Rana
|
9d0cb2cf89 |
fix(cli): cap remote file downloads in tool uploads (SEC-908) (#4417)
## Summary AppSecure SEC-908 reported that remote files fetched from user-supplied URLs were read into memory with no size cap. The core SDK (`fileUtils.node.ts`, `RemoteFile.ts`, `ToolRouterSessionFileMount.ts`) and the Python SDK already stream through a 100 MiB limit. The CLI's tool-input upload path (`ts/packages/cli/src/services/tool-file-uploads.ts`) was the last remaining sink: `readFileFromUrl` still did `response.arrayBuffer()`, so a large or never-ending response could exhaust memory before the presigned upload was even requested. Fixes SEC-908 (internal tracker). ## Changes - `@composio/core` exports `readResponseBodyWithLimit` and `MAX_URL_UPLOAD_SIZE_BYTES`, next to the existing `assertSafeFileUploadPath` export, so downstream packages reuse the one bounded reader. - CLI `readFileFromUrl` uses it in place of `response.arrayBuffer()`; behaviour is unchanged below the cap. - Regression test: a response declaring a body above the cap is rejected before `createPresignedURL` is called. - Changeset for `@composio/core` (patch). `@composio/cli` is in the changeset ignore list. ## Type of change - [x] Bug fix - [ ] New feature - [ ] Refactor/Chore - [ ] Documentation - [ ] Breaking change ## How Has This Been Tested? ``` pnpm --filter @composio/core build pnpm --filter @composio/core exec vitest run test/utils/readResponseBody.test.ts Tests 4 passed (4) pnpm --filter @composio/cli exec vitest run test/src/services/tool-file-uploads.test.ts Tests 8 passed (8) pnpm exec prettier --check <touched files> pnpm exec oxlint <touched files> ``` `tsc --noEmit` on the CLI package reports the same pre-existing errors on `next` and none in the touched files. Node 24.17.0, pnpm 11.8.0 via mise. ## Screenshots (if applicable) ## Checklist - [x] I have read the Code of Conduct and this PR adheres to it - [x] I ran linters/tests locally and they passed - [x] I updated documentation as needed - [x] I added tests or explain why not applicable - [x] I added a changeset if this change affects published packages ## Additional context The other files AppSecure listed for this finding were already capped on `next` (core: |
||
|
Alberto Schiabel
|
85996c4a1d |
fix(sdk): harden pusher auth and cross-origin redirect headers (#4406)
This PR:
- wraps `pysher.Pusher` in `_ComposioPusher`, whose channel-auth POST
carries a `(5, 15)` connect/read timeout and raises
`TriggerSubscriptionAuthError` (a `TriggerSubscriptionError`) on a
transport failure, a non-200, or a response without an `auth` token —
pysher 1.0.8 sent it with no timeout and turned a non-200 into a bare
`AssertionError` on the websocket thread, on every (re)subscribe
- keeps that POST a plain `requests.post(..., timeout=...)` rather than
routing it through `safe_request`: the endpoint is built from the
configured Composio API base URL, a fixed trusted host, not a value from
a response, and the SSRF guard would refuse a local dev base URL
- validates `pusher_cluster` against `^[a-z0-9-]+$` (non-empty, at most
64 chars) before pysher formats it into `ws-{cluster}.pusher.com`,
raising `InvalidPusherClusterError` that names the shape violation
without echoing the value
- replaces the `unittest.mock.MagicMock` stand-in for pysher's
connection logger with a dedicated `logging.Logger` (`NullHandler`,
`propagate=False`, disabled), so `unittest` leaves the runtime import
graph while raw frames stay out of user logs; a test asserts the module
source no longer mentions `unittest`
- strips `Authorization`, `Proxy-Authorization`, and `Cookie` from the
next hop when `ssrfSafeFetch` or `safe_request` follows a redirect to a
different origin; same-origin hops keep them. Manual redirect following
bypasses both `fetch`'s cross-origin rule and `requests`'
`rebuild_auth`, so neither guard applied it before — the gap #4387 left
out
- `@composio/slim` has no mirrored source (its build copies
`core/dist`), so the changeset covers `@composio/core` and
`@composio/slim` as patches
Verified with `pytest tests/test_triggers.py tests/test_url_safety.py
tests/test_path_join_guardrail.py` (192 passed), `ruff check` / `ruff
format --check` on the changed files, `mypy --config-file
config/mypy.ini` on the three changed modules with the noxfile's stub
pins (no issues), `vitest run test/utils/ssrfGuard.test.ts` in
`@composio/core` (42 passed), `pnpm typecheck` at the root (14 tasks
successful), and `oxlint` + `prettier --check` on the changed TypeScript
files.
https://claude.ai/code/session_016ZuBv7JhVdSYTLYcTy2VJr
|
||
|
Alberto Schiabel
|
b4b9fc4a32 |
fix(json-schema-to-zod): guard schema pattern compilation (#4405)
This PR: - Adds `src/utils/compile-pattern.ts` in `@composio/json-schema-to-zod`, a shared helper that compiles `pattern` and `patternProperties` keys through `new RegExp` inside a try/catch and rethrows a typed `InvalidPatternError` (exported) that names the keyword, the pattern, and the property path (e.g. `at properties.name`), mirroring the eager `assertRegexCompiles` guard in `@composio/json-schema-to-effect-schema`. - Adds a 1024-character cap on pattern length, reported through the same error with `reason: 'too-long'`. - Chooses fail-at-conversion over degrade-with-warning: the package has no warning hook or lenient `refs` mode, its sibling packages and `oneOf` handling already throw on schema defects, and a silently dropped `pattern` would widen what a tool accepts without anyone noticing. - Threads `refs.path` into `parseString` and `parseTypelessConstraints` so the error carries the property path, and appends `patternProperties.<key>` for dynamic-key objects. - Makes `@composio/core`'s `jsonSchemaToZodSchema` include the cause message in `JsonSchemaToZodError`, so the wrapped error names the malformed property without unwrapping `cause`. - Leaves out a nested-quantifier (star-height) ReDoS heuristic on purpose: it flags linear patterns such as `^(\d+\.)*\d+$`, a wrong rejection makes `tools.get` fail for the whole tool, and it cannot be validated against the live toolkit catalog without false-positive risk. Catastrophic backtracking from a hostile `pattern` remains a known limitation; only zero-false-positive guards ship here. - Adds `test/compile-pattern.test.ts` (`(` -> `InvalidPatternError` with `SyntaxError` cause, length cap, typeless and `patternProperties` paths, `^(\d+\.)*\d+$` still compiles and enforces, valid patterns still enforced) and a core test for the wrapped message; adds a patch changeset for both packages. - Verification: `pnpm test` + `pnpm typecheck` in `ts/packages/json-schema-to-zod` (4 files, 255 tests), `pnpm test` in `ts/packages/core` (54 files, 1281 passed, 2 expected fail), root `pnpm typecheck` (14/14), `lint:packages` and Prettier clean. https://claude.ai/code/session_016ZuBv7JhVdSYTLYcTy2VJr |
||
|
Alberto Schiabel
|
100d56866f |
fix(experimental): stamp eve durable callback descriptors (#4385)
This PR: - Closes https://github.com/ComposioHQ/composio/issues/4343 - stamps eve's durable callback descriptors on every tool `EveProvider` wraps, via the new internal `withDurableClosure(closure, callback)` helper — eve only stamps them on `defineTool` calls its build transform finds in the agent's own source, which never runs on this package inside `node_modules`, so eve discarded the whole resolver result and the agent silently lost every Composio tool - persists `{ slug, binding }` per callback, where `binding` is an id minted per `wrapTools` call and prefixed with a per-process token, and re-attaches it to that resolve's Composio executor through a module-level binding map. `executeTool` is bound to one Composio session, so a slug-only closure would have routed a call to whichever session resolved last; sessions for different users share one provider, and eve's callback registry is keyed by tool name only, so the map lives at module level rather than on the instance - covers `execute` and, when `needsApproval` is set, `approvalRequest`; the descriptor key is the global-registry symbol `Symbol.for('eve:durable-dynamic-callback')`, so no eve internal is imported and the stamp is inert on eve versions that predate the contract - adds 9 regression tests: descriptor presence and shape, JSON-serializability of the closure, replay of execute and approval from the closure alone, per-resolve executor isolation when sessions share a provider, hooks of the producing provider on replay, the unknown-slug and unknown-binding errors, that two fresh module instances never mint the same binding id, and one suite that loads eve 0.52.1's own `validateDurableDynamicToolCallbacks`, `replayDynamicTools`, and callback registry from the installed package to validate and replay a wrapped tool end to end. Before the change eve threw `Dynamic tool "..." callback "execute" does not have a durable descriptor` ## Context The reporter hit this on eve 0.50 as `non-serializable capture`; 0.52.1 reports the same root cause as a missing descriptor. eve exports no public durable-callback helper (tracked at vercel/eve#2967), so the provider stamps the descriptor itself rather than pinning users to an older eve. Bindings are kept for the life of the process: eve can resume a parked call at any time. A binding lives only in the process that resolved the tools, so a call parked across a restart cannot be replayed; the per-process token in the id makes the stale closure fail the lookup loudly instead of matching whichever resolve reused its counter value in the new process. Growth is one entry per `session.tools()` resolve. Docs (`/docs/providers/eve`) now state the contract, the restart limit, and the real reason the `step.started` resolver runs each step (principal re-evaluation and retry, cached per session). Also unblocks `Docs - Tests` on this branch: the catalog refresh in #4330 renamed Stripe's triggers, so the Stripe knowledge-base guide cited two dead slugs and the corpus verifier failed for any PR touching docs. The guide now cites only the renamed slug the catalog lists, and `generate-toolkits.ts` fetches trigger types with `limit=1000` so the catalog stops truncating every toolkit to its first 20 triggers. https://claude.ai/code/session_019wRk1S4Z6V6FWr4UsybGvR EOF -R ComposioHQ/composio |
||
|
Alberto Schiabel
|
ba85f4d183 |
fix(sdk): honor Fetch redirect semantics in both SSRF guards (#4387)
This PR: - builds on top of https://github.com/ComposioHQ/composio/pull/4271, whose commit it carries unchanged - applies the Fetch standard's redirect method/body rules in **both** SSRF guards via `_redirect_rewrite` / `redirectRewrite`: a `303` retries as a bodiless request, a `301`/`302` does the same for a `POST`, and `307`/`308` replay both - narrows `ssrfSafeFetch` to the five statuses the Fetch standard calls a redirect, so a `304` or `305` carrying a `Location` is returned to the caller instead of followed — Python already used `_REDIRECT_STATUS_CODES` - drops `params` after the first hop in `safe_request`, since `Location` carries the query for the target it names and re-appending handed a query-string credential to a target that never asked for one - purges the union of the Fetch `request-body-header` set and the two `requests` also drops, identically on both sides - blocks the IPv6 transition ranges the TypeScript CIDR list missed — 6to4 `2002::/16`, Teredo and the rest of `2001::/23`, local-use NAT64 `64:ff9b:1::/48`, `100::/64`, `2001:db8::/32`, site-local `fec0::/10` — and the IPv4/IPv6 multicast and `192.88.99.0/24` ranges Python's `is_global` missed ## Context Both guards follow redirects by hand so every hop is revalidated against the address blocklist. That also means neither inherits the method and body rewriting `fetch` and `requests` would have done, so an upload answered with a `303` was replayed — payload and all — at a result URL that expects a GET. https://github.com/ComposioHQ/composio/pull/4271 landed that rule in Python only, which left the two SDKs disagreeing on the same wire behavior. Reviewing for that divergence surfaced the redirect-status set, the `params` replay, and the address-blocklist gaps above. `2002:7f00:1::` is 6to4 for `127.0.0.1`, and it passed the TypeScript guard as a public address. Verified with `pytest python/tests/test_url_safety.py` (56 passed) and `vitest run` in `@composio/core` (54 files, 1280 passed), plus `ruff`, `tsc --noEmit`, `oxlint` and `prettier`. Fail-before confirmed: 10 of the new TypeScript cases and 5 of the new Python cases fail against the unmodified guards. Two known gaps are deliberately left out, each deserving its own change: neither guard strips `Authorization`/`Cookie` on a cross-origin redirect, and a non-seekable Python body is re-sent exhausted on a `307` where TypeScript throws a bare `TypeError` on a consumed `ReadableStream`. https://claude.ai/code/session_01SB3ZJdvoqBcRrWb2toWVrX --------- Co-authored-by: ump45nose <52391318+ump45nose@users.noreply.github.com> |
||
|
Alberto Schiabel
|
705591451c |
chore(deps): upgrade CI actions and every outdated dependency (#4381)
This PR: - upgrades every CI action to its latest release (only `changesets/action` had one: v2.1.1 -> v2.1.2, SHA-pinned) and every outdated dependency across the pnpm workspace, the docs bun workspace, and all three `uv.lock` files - moves zod to 4.5.4 everywhere first-party — catalog, docs, `@composio/json-schema-to-zod`, `@composio/claude-agent-sdk` and the zod-v4 e2e fixtures; the `*-zod-v3` fixtures stay on 3.25.76 because that is what they exercise - moves `@mastra/core` 1.52.1 -> 1.53.0, which is the ceiling rather than a preference: bisecting `ts/examples/mastra`'s `cf:dry-run` shows 1.54.0 moved the workspace/sandbox subsystem behind `@mastra/core/agent`, which drags execa (-> `npm-run-path` -> `unicorn-magic`) into the Workers bundle where esbuild cannot link it. `@mastra/mcp` is capped at 1.17.2 for the same reason — 1.17.3 wants `@mastra/core` >=1.64. The docs bun workspace mirrors that cap as an explicit devDependency plus `overrides` entry, because bun does not apply overrides to auto-installed peers - clears every production advisory that has a published fix, so the audit gate can run without `--ignore`, which does not filter a single run: it writes the advisory into `auditConfig` and exits 0 whatever else is outstanding, so the gate was passing over nine advisories - `qs` -> >=6.16.0, `fast-uri` -> >=3.1.6, `toml` -> the 4.x line, all via overrides in the existing `# temporary: … drop when` style - `extract-zip` (GHSA-jmr9-qjv8-65gv) has no fixed version to move to — 2.0.1 is the newest release and GitHub records `first_patched_version` as null — so it moves to `auditConfig.ignoreGhsas` pointing at the `extractZipSafely` mitigation that already covers it - GHSA-866g-f22w-33x8 (`@ai-sdk/provider-utils` 3.x, low) also has nothing to move to: the advisory names 3.0.98 as patched but the 3.x line stopped at 3.0.30 and GitHub records no fixed version. It only enters the tree through `@mastra/core`, which is a peer or dev dependency of every published package, so all flagged paths are private examples and e2e fixtures. It goes in `ignoreGhsas` with that rationale so the un-levelled `pnpm audit --prod` step stops posting a warning comment on every PR - widens `@composio/anthropic`'s `@anthropic-ai/sdk` peer range to include `^0.124.0`, the line its devDependency now tests against (for a `0.x` caret, `^0.120.0` excluded it); the package is in the changeset for that reason - adapts three call sites that upstream broke: `eve` 0.52 moved `ApprovalContext` to `eve/tools/approval`, `@pierre/diffs` 1.4 gave `FileDiffProps` a second type parameter, and `fumadocs-openapi` 11.4 fixed the undeclared-tag drop that a docs guard test asserted (the guard now also asserts the page positively, so it cannot pass vacuously) - drops the stale `hono` `minimumReleaseAgeExclude` entry (its comment said to after 2026-08-06) and adds an `undici` `peerDependencyRules` allowance for openai 7.10's new optional peer ## Context Some upgrades were deliberately declined, each for a reason recorded next to the pin: - `vitest`/`@vitest/ui` stay on 4.1.11 — `@cloudflare/vitest-pool-workers@0.22.0` (latest) peers on `vitest ^4.1.0` - `undici` stays on `^7` in core — `pinnedDispatcher.node.ts` documents that Node's `fetch` rejects undici 8 dispatchers - the `pnpm` catalog entry stays on `^11` to match the mise-owned toolchain - `eve` stays on 0.27.6 in docs — 0.52 changes the `defineAgent` model definition and the `useEveAgent` helpers, so `agent/agent.ts` and `components/eve-chat.tsx` fail `types:check`; migrating the docs agent is its own PR - `@earendil-works/pi-coding-agent` stays on 0.84.4 — 0.85.x imports `@earendil-works/pi-server` without declaring it, so `test/pi.test.ts` fails to load `declareOperationTags` is kept as a safety net rather than retired, even though `fumadocs-openapi` 11.4 makes it redundant: removing it changes how specs are normalised at sync time and is worth its own PR. Verified locally: `pnpm build:packages`, `pnpm typecheck`, `pnpm test`, `pnpm typecheck:examples`, `pnpm lint:examples`, `turbo cf:dry-run --filter='./ts/examples/*'`, `pnpm peers check`, `pnpm audit --prod --audit-level=high` (exit 0), frozen-lockfile installs for pnpm and bun, docs `types:check` + 542 static tests, and Python `make chk` + `make tst` (1790 passed). https://claude.ai/code/session_018evFic47PFPXuB95uRE1aw EOF -R ComposioHQ/composio |
||
|
Alberto Schiabel
|
0fb479b8f1 |
Merge commit from fork
* fix(cli): escape generated source metadata * test(cli): execute generated Python regression * fix(cli): order Python fallback assignments --------- Co-authored-by: jkomyno <12381818+jkomyno@users.noreply.github.com> |
||
|
Alberto Schiabel
|
230f81a737 |
refactor(cli): import @effect/platform modules by subpath (#4360)
This PR: - rebases onto `next` now that https://github.com/ComposioHQ/composio/pull/4358 and https://github.com/ComposioHQ/composio/pull/4359 are merged - rewrites every `@effect/platform` and `@effect/platform-bun` barrel import under `ts/packages/cli` (155 statements in 112 files) as a per-module namespace import, e.g. `import * as FileSystem from '@effect/platform/FileSystem'` - adds both barrels to the `no-restricted-imports` lists for `ts/packages/cli/src`, with messages pointing at the subpath form - updates the boundary guidance in `ts/packages/cli/AGENTS.md` and the `cli-command` skill to the subpath form ## Context Both barrels are pure namespace re-exports (60 and 19 modules), so this is import-only with no runtime change. Effect v4 spreads these modules across `effect` (`FileSystem`, `Path`, `PlatformError`), `effect/unstable/http`, and `effect/unstable/process`; with per-module imports the port becomes a scripted path rewrite instead of hand-splitting each barrel line. Third of three preparation PRs. ## Validation - `pnpm --filter @composio/cli typecheck` and oxlint clean; a probe barrel import in `src/` is rejected by the new rule - `pnpm --filter @composio/cli test`: 127 files, 1318 tests pass, 1 skipped |
||
|
Alberto Schiabel
|
f5ff810f2e |
refactor(cli): define services with Context.Tag and thread argv explicitly (#4359)
This PR: - builds on top of https://github.com/ComposioHQ/composio/pull/4358 - replaces the eleven `Effect.Service` files (fourteen services) with `Context.Tag` classes that export a `<Name>Shape` type and an explicit `static readonly Default` layer built from a `make<Name>` constructor - removes the three `accessors: true` declarations; nothing in `src/` used a generated accessor, and the one test that did now yields the service - builds test doubles with `Service.of({ ... })` instead of `new Service({ ... })`, and types helper parameters with the `Shape` types where the class had been used as a type - passes the normalized argv from `bin.ts` into `runCli` and through `cli-main.ts` instead of mutating `process.argv` and reading it back in five places - documents the service pattern in `ts/packages/cli/AGENTS.md` ## Context Effect v4 replaces `Effect.Service` with `Context.Service`, which generates neither a `.Default` layer nor accessors; with the explicit-layer shape already on v3, the port turns each service into a one-line rename. `Command.runWith` in `effect/unstable/cli` takes user arguments explicitly, so `cli-main.ts` now receives argv rather than re-reading process state. Second of three preparation PRs. ## Validation - `pnpm --filter @composio/cli typecheck`, `validate:boundaries`, and oxlint clean - `pnpm --filter @composio/cli test`: 127 files, 1319 tests pass, 1 skipped |
||
|
Alberto Schiabel
|
20aaa95c96 |
ci(ts): verify packed provider compatibility (#4355)
This PR: - adds a clean consumer harness that packs core, its internal JSON Schema dependency, and all ten TypeScript providers - verifies tarball contents, npm installation, named public exports, consumer typechecking, provider construction, and a credential-free `wrapTool` conversion - covers the current workspace core, one verified minimum-core lane per provider, and the packed workspace core presented as `1.0.0-beta.0` - preserves existing 0.x minimum peer ranges while recording the verified floors separately for the future breaking release - additively accepts core 1.0 prereleases without claiming stable 1.x support yet - widens the Anthropic and OpenAI Agents peer ranges to include the upstream versions already used by this repository - runs the gate in TypeScript CI and immediately before Changesets publishing The release guard fails before publication and its regression test verifies build -> compatibility -> publish ordering plus failure propagation. ## Non-breaking scope No public API is removed or renamed, and the existing 0.x core peer floors remain unchanged. All peer-range changes are additive. The gate reports the nine floor corrections that should be made with the planned breaking release. ## Validation - `pnpm run check:provider-compatibility` (12 packed consumer lanes) - `pnpm run test:provider-compatibility` - `pnpm run test:release-workflow` - `pnpm run build:packages` (19 packages) - focused TypeScript compile and Oxlint checks - Prettier, Changesets validation, and `git diff --check` |
||
|
sdkrelease[bot]
|
61c3cb6481 |
chore(cli): refresh baked toolkit slugs (#4372)
## Summary Automated refresh of the toolkit slugs the CLI knows without asking the API, generated by `ts/packages/cli/scripts/generate-toolkit-slugs.ts`. Toolkits added since the last refresh currently cost users one toolkit-list fetch (~2 s) the first time they run one of that toolkit's tools. Merging this makes them free. The generator refuses to write a list that is short, malformed, or missing staple toolkits, so a bad fetch opens no PR at all. Co-authored-by: jkomyno <12381818+jkomyno@users.noreply.github.com> |
||
|
Alberto Schiabel
|
d4077ba415 |
chore(cli): trim unused Effect packages and unify version output (#4358)
This PR: - drops the eight `@effect/*` satellite devDependencies and `@effect/platform-node-shared` from `@composio/cli`; none is imported by the CLI, its tests, or its scripts, and the `@effect/platform-node-shared` catalog entry goes with them - makes `--log-level` fall back to `COMPOSIO_LOG_LEVEL` when the flag is absent (`Option.orElse` instead of `Option.zipLeft`, which discarded the env value) and adds a precedence test - rewrites `composio --version` and `composio -v` to the `version` command before parsing, so the three spellings share one handler and print identical output (the framework built-in used to add a trailing blank line); CI and the installer keep using `composio --version` ## Context First of three preparation PRs for the Effect v4 port; https://github.com/ComposioHQ/composio/pull/3901 is the reference port. Each lands v3-compatible groundwork that the port otherwise has to redo on top of a large diff: the manifest, catalog, and lockfile were three of the conflicting files in that PR, and its review had accepted Effect v4's default `composio v<semver>` banner for `--version`. Owning the flag in argv normalization keeps `--version` output stable across the framework change instead. ## Validation - `pnpm --filter @composio/cli typecheck` and oxlint clean - `pnpm --filter @composio/cli test`: 127 files, 1318 tests pass, 1 skipped; `version`, `--version`, and `-v` are asserted byte-identical - The Docker install e2e suite was not run locally; `cli.install-e2e.yml` runs it on this PR |
||
|
sdkrelease[bot]
|
2573c64d97 |
Release: update version (#4285)
This PR was opened by the [Changesets release](https://github.com/changesets/action) GitHub action. When you're ready to do a release, you can merge this and the packages will be published to npm automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to next, this PR will be updated. # Releases ## @composio/claude-agent-sdk@0.12.0 ### Minor Changes - |
||
|
Alberto Schiabel
|
ab289d6224 |
fix(sdk): preserve primitive JSON Schema semantics (#4316)
## Summary - preserve boolean, empty, null, type-array, enum, const, and scalar-constraint semantics across every Python conversion entry point - intersect Zod enum and const values with declared types and constraints, including compound JSON values - default unversioned exact validation to Draft 7 and apply inclusive and numeric exclusive bounds independently - run one byte-identical corpus through Python, Zod, and Effect so accepted and rejected inputs stay aligned - keep exact JSON Schema acceptance separate from Pydantic default materialization ## Review follow-up (second push) - Python: exact Draft 7 acceptance now wraps all three entry points (`json_schema_to_pydantic_type`, `json_schema_to_model`, `pydantic_model_from_param_schema`), so they can no longer disagree - Python: draft-4 boolean `exclusiveMinimum`/`exclusiveMaximum` (OpenAPI 3.0 style) no longer crash conversion — exact validation falls back to Draft 4, and the library input is translated to the numeric spelling - Python: ECMA-only regex patterns (look-around) no longer crash pydantic model builds — Rust-incompatible patterns fall back to Python `re` - Python: type arrays with sibling constraints no longer raise `TypeError` on valid input — constraints are scoped per member before the library sees them - Python: integral floats satisfy `integer`, `const` intersects `enum`, annotation-only schemas accept anything, and an optional property with an empty `enum` tolerates absence - Zod: typeless scalar constraints apply per instance type, and string lengths count Unicode code points instead of UTF-16 code units - Effect: draft-4 boolean exclusive bounds are enforced instead of silently ignored - `multipleOf` uses decimal scaling in all three converters (declared `divergesFromJsonSchema` on the corpus case) - shared corpus grows by 13 primitive cases; new property-based tests check acceptance against real Draft 7 oracles (hypothesis + `jsonschema` in Python, fast-check + Ajv in TypeScript) ## Verification - Python `make chk` (ruff + mypy) - Python pytest: 1,572 passed (5 langchain-extra tests need an env this sandbox lacks; unchanged from base) - `@composio/json-schema-to-zod`: 187 passed incl. 300-run fast-check property test; typecheck + build - `@composio/json-schema-to-effect-schema`: 133 passed; typecheck - `@composio/core` corpus ingress tests: 61 passed - shared Python/TypeScript corpus files are byte-identical (shasum-verified) - `git diff --check` ## Contributor context This replaces four narrow proposals after independent local reproduction: - [#4301](https://github.com/ComposioHQ/composio/pull/4301) · [Glen](https://app.tryglen.com/ComposioHQ/composio/pull/4301) - [#4302](https://github.com/ComposioHQ/composio/pull/4302) · [Glen](https://app.tryglen.com/ComposioHQ/composio/pull/4302) - [#4303](https://github.com/ComposioHQ/composio/pull/4303) · [Glen](https://app.tryglen.com/ComposioHQ/composio/pull/4303) - [#4307](https://github.com/ComposioHQ/composio/pull/4307) · [Glen](https://app.tryglen.com/ComposioHQ/composio/pull/4307) --------- Co-authored-by: simpleqt <89645338+simpleqt@users.noreply.github.com> |
||
|
CoralGarden52
|
7420927183 |
fix(sdk): qualify custom toolkit child slug mapping across Python and TypeScript (#4311)
## Summary The Python SDK treated a custom tool's `original_slug` as globally unique, rejecting valid custom toolkits that reuse common child names such as `SEARCH`, `VERSION`, or `GREP` even though the backend-assigned final slugs are toolkit-qualified (`LOCAL_ALPHA_GREP`, `LOCAL_BETA_GREP`). This ports the toolkit-qualified lookup from #3360 to Python, then fixes three response-mapping bugs found in review and applies the same fixes to the TypeScript SDK so both stay in parity. ## Changes ### Python (`composio`) - Scope custom-tool collision detection and response matching by toolkit plus original slug. - Keep bare original-slug aliases only when unambiguous; `session.execute("GREP")` raises with the final slugs to use when the slug is shared. - Preserve toolkit-qualified final slugs in `custom_toolkits()`. - `build_custom_tools_map_from_response`: raise when a response tool has local handles but no exact toolkit match instead of silently dropping it or binding another toolkit's handler; only fall back to a bare match when the response carries no toolkit identity; reject duplicate qualified response entries; derive bare-slug ambiguity from local definitions so omitting a sibling in the response never makes the survivor callable by bare name. - `custom_toolkits()` only reuses a bare alias that belongs to the same toolkit. - Docstring and Python session reference page state that bare-slug execution requires a unique original slug. ### TypeScript (`@composio/core`) - Same four fixes in `buildCustomToolsMapFromResponse` and the same guard in `customToolkits()`. - JSDoc and TypeScript session reference page updated. - Changeset: patch for `@composio/core`. ### Not changed - `COMPOSIO_MULTI_EXECUTE_TOOL` still aborts the whole batch when one item uses an ambiguous bare slug, matching current TS behavior. Switching to per-item errors is a cross-SDK design change left for a follow-up. ## Type of change - [x] Bug fix - [ ] New feature - [ ] Refactor/Chore - [ ] Documentation - [ ] Breaking change ## How Has This Been Tested? Python: - `pytest tests/test_custom_tools.py tests/test_tool_router.py`: 181 passed. - ruff (project config) clean; mypy reports no errors in the touched files. - New tests: sibling routing, multi-execute, preload rejection, listing guard, and five response-mapping cases (no exact match, cross-toolkit binding, standalone bare fallback, unknown response tools skipped, ambiguity from local definitions, duplicate qualified entries). TypeScript: - `vitest run` in `ts/packages/core`: 53 files, 1251 passed, 2 expected failures. - `tsc --noEmit` clean; prettier and oxlint via pre-commit hook. - New tests: cross-toolkit reuse in `buildCustomToolsMap` and a new `buildCustomToolsMapFromResponse` block mirroring the Python cases. Python and TypeScript CI do not run automatically on this fork PR; a maintainer needs to approve the workflow run. ## Checklist - [x] I have read the Code of Conduct and this PR adheres to it - [x] I ran linters/tests locally and they passed - [x] I updated documentation as needed - [x] I added tests or explain why not applicable - [x] I added a changeset if this change affects published packages ## Additional context Reviewed with a second opinion from Codex (gpt-5.6-sol), which flagged the wrong-handler binding and response-derived ambiguity bugs fixed in the follow-up commits. https://claude.ai/code/session_01Y7Ni3QEBDGShSrEtwQS5bA EOF -R ComposioHQ/composio --------- Signed-off-by: CoralGarden52 <2193436736@qq.com> Co-authored-by: jkomyno <alberto@composio.dev> Co-authored-by: Alberto Schiabel <jkomyno@users.noreply.github.com> |
||
|
CoralGarden52
|
52efb5b833 |
fix(core): respect authConfigId in trigger subscriptions (#4298)
## Summary - Apply the existing authConfigId subscription filter to incoming trigger events. - Add a V3 regression test for mismatched auth configurations. - Add a patch changeset for @composio/core. Previously, a subscription filtered by authConfigId still invoked its callback for events belonging to a different auth configuration. ## Verification - Vitest targeted tests: 76 passed - Vitest core suite: 1244 passed, 2 expected failures - TypeScript typecheck and Prettier passed Fixes the missing authConfigId filtering in trigger subscriptions. --------- Co-authored-by: jkomyno <alberto@composio.dev> |
||
|
Alberto Schiabel
|
0d28befb14 |
fix(sdk): map streamed file transport failures (#4321)
## Summary - map Python file-fetch failures that occur after response headers into the documented upload and download errors - map TypeScript RemoteFile connection and streamed-body failures into RemoteFileDownloadError while preserving blocked-URL errors - close or cancel response bodies on every exit and apply the shared 100 MiB response limit to TypeScript RemoteFile downloads This supersedes the Python-only proposal in #4305 and carries the same failure category across both SDKs. ## Independent reproduction A response double returned one chunk and then raised a connection-reset error. On current next: - Python _fetch_file_from_url leaked ConnectionError, although it did close the response - Python Tool Router URL fetch leaked ConnectionError and left the response open - TypeScript RemoteFile leaked the native fetch/body TypeError instead of RemoteFileDownloadError ## Verification - Python make chk - Python make tst: 1,490 passed - TypeScript core typecheck - TypeScript core tests: 1,245 passed, 2 expected failures - TypeScript package build: 19 packages - focused Python regression tests: 3 passed - focused TypeScript RemoteFile tests: 17 passed |
||
|
Alberto Schiabel
|
95f9d3295f |
fix(cli): guard URL file uploads against SSRF (#4319)
## Summary - route attacker-controlled URL sources and API-provided presigned upload destinations through the runtime-conditional core SSRF guard - expose that guard through a Node/workerd-aware core subpath - validate and revalidate DNS on redirects, pin Node and Bun connections to validated addresses, and preserve configured proxy routes - fail closed for user-chosen URL uploads in edge runtimes - cancel ignored response bodies and cover both upload boundaries at the public CLI pipeline - avoid adding `Content-Length: 0` to bodyless Bun GET requests ## Local reproduction On `next`, the CLI pipeline used bare `fetch` for both targets. A local loopback source and an internal presigned destination reached the network path. With this branch, the real `uploadToolInputFiles` pipeline blocks a `127.0.0.1` source before presigning and a `169.254.169.254` destination before sending bytes. A direct Bun proof also confirmed the pinned transport reaches a validated address without calling native `fetch`, while retaining the original Host header. Focused tests preserve native Bun fetch when an environment proxy is configured. ## Cross-SDK parity Python already applies public-address validation, redirect checks, DNS pinning, and response limits to URL uploads. Its focused URL-safety and upload suite remains green: 62 passed. No Python behavior change was needed. ## Verification - `pnpm build:packages`: 19 packages built - root `pnpm typecheck`: 14 package checks passed - TypeScript core: 53 files, 1,246 passed and 2 expected failures - focused core SSRF and pinned-transport tests: 31 passed - Python URL-safety/upload tests: 62 passed - real Bun execution of both CLI upload boundaries: blocked before presign/send - `git diff --check` The CLI Effect test file contains source and presigned-destination regressions and typechecks. Its local runner is blocked on current `next` by the repository-wide `@effect/vitest` config failure; hosted CLI checks exercise that boundary. ## Contributor context Supersedes [#4299](https://github.com/ComposioHQ/composio/pull/4299) · [Glen](https://app.tryglen.com/ComposioHQ/composio/pull/4299) after independently reproducing the attack path. The report is valid and useful, but the proposed root export hard-coded a Node module into an edge-capable package, its happy-path test did not execute the returned Effect, and it omitted destination protection, response cleanup, and Bun address pinning. |
||
|
Alberto Schiabel
|
be8e978c3a |
fix(toolchain): pin Bun canary for valid macOS signatures (#4315)
This PR: - closes #4284 - makes `mise.toml` the editable source of truth for Bun and pins `1.4.1-canary.1+d9b769812`, the first Bun build whose compiled macOS binaries carry strictly valid signatures - maps that revision to the immutable per-platform `@oven/bun-*` npm tarballs via mise's `http` backend, so mise extracts the exact checksum-verified binary with no npm lifecycle, Node dependency, or postinstall script - installs Bun through mise in CI and Docker E2E images, removing the independent `bun-version` input and the `oven-sh/setup-bun` channel - updates the checksum-verified mise installer to `2026.8.15`, reuses it in the Docker E2E images, and regenerates `mise.lock` with that release - teaches the preinstall toolchain check to compare the full Bun revision (via `Bun.version_with_sha`, in-process) when the pinned version carries build metadata - verifies the exact `bun --revision`, a strictly valid Bun-compiled macOS signature, a Linux container install, the release-workflow contract, and formatting/linting EOF -R ComposioHQ/composio |
||
|
Alberto Schiabel
|
1d31c80eff |
fix(sdk): keep credentials private in storage and logs (#4318)
## Summary - write CLI user data, pending login sessions, and agent identities through one atomic `0600` helper - repair `0644` credential files created by older CLI versions before reading them - redact credential-shaped structured values from CLI user-context diagnostics - redact secret-shaped text at both TypeScript and Python SDK log-output boundaries, including Pusher `auth` responses and exception tracebacks - preserve Python logger compatibility: errors remain untruncated, disabled levels remain lazy, and malformed placeholders cannot expose arguments ## Local reproduction Under the normal `022` umask, `next` created a plaintext credential file with mode `0644`. The pre-fix CLI user-context and TypeScript SDK debug paths also emitted sentinel credentials. The private atomic writer changes an existing `0644` target to `0600`, and the upgrade tests now prove all three legacy credential files are tightened without changing their contents. ## Verification - CLI permission upgrade tests: 31 passed across user data, pending login, and agent identity paths - CLI source and test typechecks passed - TypeScript core logging, redaction, and Pusher tests: 17 passed - TypeScript core source and type-test typechecks passed - Python logging regression tests: 5 passed - focused Ruff, Prettier, Oxlint, and `git diff --check` passed The focused CLI runner needed a temporary local alias for the pre-existing missing `#ssrf_guard` mapping in the CLI Vitest config. The alias was removed after verification and is not part of this PR. ## Contributor context Credit to **Syed Anas Mohiuddin**, independent security researcher, for reporting the legacy CLI credential-file permission issue. Supersedes [#4300](https://github.com/ComposioHQ/composio/pull/4300) · [Glen review](https://app.tryglen.com/ComposioHQ/composio/pull/4300). The implementation also covers agent credentials, retains atomic writes, and applies redaction at the shared SDK logging boundary. |
||
|
Saransh Rana
|
961b0a0418 |
security: fix Parameter finding #91 (CWE-94) - identifier guard in ts-builders codegen (#4324)
## What the vulnerability was
The CLI's TypeScript generator wrote API-supplied tool and trigger slugs
straight into generated `.ts` files at two places where the slug becomes
**code**, not data:
- **object-literal property keys** (`PropertyValue.write`), and
- **type-declaration names** (`TypeDeclaration.write`).
Slugs are unconstrained strings (`ToolAsEnum = Schema.String`, no
character allowlist) and the threat model treats API responses as
untrusted. So a crafted slug could close the key and inject arbitrary
top-level TypeScript, which then executes when the generated SDK is
imported or built. That is remote code execution on the developer or CI
host running `composio ts generate`.
The sibling `Property` builder already got this right: it tests
`isValidJsIdentifier` and falls back to a JSON-encoded computed key.
`PropertyValue` and `TypeDeclaration` simply lacked the same guard.
## Why this change addresses it
- `PropertyValue` now applies the exact guard `Property` uses. A name
that is not a valid identifier becomes a quoted computed key
(`["..."]`), so everything it contains is parsed as a string, never as
an expression.
- `TypeDeclaration` refuses a non-identifier name with a `TypeError`. A
type name has no quoted or computed form, so quoting is not available
and failing loudly is the only safe option. The guard sits after the
existing early return for a string type body, which never writes the
name.
Output is byte-identical for every name that is already a valid
identifier, so no existing generation changes. The CLI codegen snapshots
contain only identifier-shaped slugs
(`GITHUB_ACCEPT_A_REPOSITORY_INVITATION_INPUT`) and no computed keys,
and they are unchanged.
Worth noting on the throw: the two sinks differ in exposure.
`typeDeclaration` receives the full `tool.slug` (for example
`GITHUB_FOO`), which is identifier-shaped in practice. `propertyValue`
receives `stripPrefix(tool.slug)`, which can plausibly start with a
digit for real data and now gets safely quoted rather than throwing. Any
name that would now throw was already producing syntactically invalid
TypeScript, so this converts a confusing downstream compile error into a
clear codegen error.
## Tests
**Exploit tests**, not behaviour-pinning. Nine new tests across the two
files.
The key one builds the generated object literal from a malicious slug,
evaluates it, and asserts the injected IIFE did not run:
```ts
const evaluated = new Function(`return { ${out} };`)() as Record<string, unknown>;
expect(Object.keys(evaluated)).toEqual([malicious]);
expect((globalThis as Record<string, unknown>).__PWNED__).toBeUndefined();
```
Each test was confirmed to fail against the unpatched builders and pass
after the change. On the vulnerable code the generator emits `["k"]: (()
=> { globalThis.__PWNED__ = 1; })(), ["SEND"]: "SLACK_SEND"`, which is
the payload as live code.
Existing behaviour is also pinned: valid identifier keys, well-known
symbols, optional properties, generic parameters, doc comments, and the
string-type-body short circuit.
## What was not verified
- **No end-to-end run of `composio ts generate` against a real or
malicious API response.** The fix and its tests are at the builder
layer. The call sites in
`ts/packages/cli/src/generation/typescript/generate-toolkit-sources.ts`
were read to confirm they pass attacker-controlled slugs into these
builders, but were not exercised.
- **No model-layer slug validation was added.** The finding also
suggests validating slugs against `^[A-Za-z0-9_]+$` at the model layer.
That is deliberately out of scope here: it would change what the CLI
accepts from the API and belongs in a separate, human-reviewed change.
This PR closes the two injection sinks only.
- **The `TypeDeclaration` throw is a new failure mode.** If any live
toolkit ships a slug that is not a valid identifier, codegen will now
fail loudly for it instead of emitting broken TypeScript. No such slug
appears in the repo's fixtures, but the full set of production slugs was
not enumerated.
- Python codegen was not reviewed. This finding and fix are
TypeScript-only.
## Testing performed
Clean-HEAD baseline captured before any edit: full monorepo `pnpm run
test` green, 26/26 turbo tasks, exit 0.
After the change, the same full suite is green, 26/26 tasks, exit 0.
`@composio/ts-builders` goes from 131 to 140 tests, all passing.
`@composio/cli` unchanged at 1304 passed. 20 example packages validated.
No new failures and no snapshot churn.
## Finding
Parameter finding #91 (CWE-94), validated live at
`abc8e038218305cab7f3373b82a37144fa15e630`.
Linear: https://linear.app/composio/issue/SEC-579
parameter-finding: kcy19unq784bp2z34b3299w0
Co-authored-by: Saransh <saranshrana@Saranshs-MacBook-Pro.local>
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
||
|
Alberto Schiabel
|
28378595a1 |
fix(providers/anthropic): re-export AnthropicTool, InputSchema, and CacheControlEphemeral types (#4286) (#4295)
## Summary - Re-exports `AnthropicTool`, `InputSchema`, and `CacheControlEphemeral` types from `@composio/anthropic` entry point (`ts/packages/providers/anthropic/src/index.ts`). - Allows TypeScript users to import schema types directly without reaching into internal paths. ## Test Plan - Verified index exports in `@composio/anthropic`. |
||
|
Alberto Schiabel
|
7da1397017 | Merge branch 'next' into fix/cli-spinner-narrow-terminal-scroll | ||
|
jkomyno
|
41019972e1 |
fix(cli): harden spinner message clamping
Keep live spinner updates within both Clack's construction-time width and the current terminal width, so resizing wider cannot reintroduce wrapped frames while narrower terminals remain clamped. Segment messages by grapheme cluster before measuring display width so keycap and joined emoji cannot be under-counted or split. |
||
|
jkomyno
|
26eedbf5c8 | chore(cli): refresh baked toolkit slugs | ||
|
jkomyno
|
6b135d1606 |
refactor(cli): start clamped spinners in one place
Both spinner entry points constructed a clack spinner on stderr and started it with a clamped message, and useMakeSpinner built a throwaway lambda purely to relay that same clamp into createClackSpinnerHandle. Give makeTerminalUI a startSpinner helper that both entry points call, and let createClackSpinnerHandle take the output stream it clamps against instead of a pre-bound closure. Behaviour is unchanged. Claude-Session: https://claude.ai/code/session_0191yFPnWgJnzPPnCYrVm6X7 |
||
|
teddiesloco
|
f438422df0 | fix(providers/anthropic): re-export AnthropicTool, InputSchema, and CacheControlEphemeral types (#4286) | ||
|
jkomyno
|
4e45d7fabe |
fix(cli): clamp spinner messages by display width
Follow-ups from review of the narrow-terminal spinner fix. - Budget and truncate by display columns instead of UTF-16 code units. Clack wraps the rendered frame by width, so a CJK message sat under a `.length` budget and wrapped anyway, reinstating the leak. Walking whole code points also keeps the cut off a surrogate pair. - Drop MIN_SPINNER_MESSAGE_COLUMNS. The 8-column floor exceeded the row below ~15 columns and restored the scroll it was meant to prevent. The budget now degrades to the ellipsis, so the one-row invariant holds wherever it can hold at all. - Cover the paths production actually drives: live `message()` updates and `withSpinner`'s start message. Reverting either clamp previously left the whole suite green. - Advance fake timers past clack's dot animation so the three dot columns SPINNER_RENDER_OVERHEAD reserves are exercised, and run these cases through `it.live` per the package's Effect test convention. - Add the CHANGELOG entry this user-facing fix needs; `@composio/cli` is changeset-ignored, so release notes go there directly. Claude-Session: https://claude.ai/code/session_0191yFPnWgJnzPPnCYrVm6X7 |