Commit Graph

4252 Commits

Author SHA1 Message Date
hex-security-app[bot] 17fe881059 fix: apply automated code update (#3600)
This pull request contains an automated code update generated by Hex.

Please review the diff carefully before merging.

---
_Generated by Hex Security. Please review carefully before merging._

---------

Co-authored-by: Hex Security <255204168+hex-security-app[bot]@users.noreply.github.com>
Co-authored-by: jkomyno <alberto@composio.dev>
@composio/cli@0.2.32-beta.272
2026-06-24 18:56:20 +04:00
Kshitiz 446c6f65bf fix(cli): unify virtual TypeScript compiler host resolution (#3182)
## Summary
This PR resolves the TODO in
`ts/packages/cli/src/generation/typescript/transpile.ts` by extracting
the shared virtual TypeScript compiler-host logic used by both
production transpilation and test validation.

While doing that refactor, it also fixes a real virtual
module-resolution issue: TypeScript may resolve in-memory files using
`./file.ts`, `file.ts`, or absolute paths, and the previous setup did
not handle those lookups consistently.


## Changes
- added
`ts/packages/cli/src/generation/typescript/virtual-compiler-host.ts`
- extracted shared helpers for virtual file-map creation, compiler-host
patching, and diagnostic formatting
- updated `ts/packages/cli/src/generation/typescript/transpile.ts` to
use the shared helper
- updated `ts/packages/cli/test/__utils__/typescript-compiler.ts` to use
the same shared helper
- updated affected tests to validate complete generated module sets
instead of incomplete single-file inputs
- added a patch changeset for `@composio/cli`

## Type of change
- [x] Bug fix
- [x] Refactor/Chore

## How Has This Been Tested?
Ran focused checks on the touched CLI TypeScript
generation/compiler-host paths:

```bash
pnpm --dir ts/packages/cli exec prettier --check src/generation/typescript/transpile.ts src/generation/typescript/virtual-compiler-host.ts test/__utils__/typescript-compiler.ts test/src/generation/typescript/generate.test.ts test/src/commands/ts/ts.generate.cmd.test.ts
pnpm --dir ts/packages/cli exec vitest run test/__utils__/typescript-compiler.ts
pnpm --dir ts/packages/cli exec vitest run test/src/generation/typescript/generate.test.ts

---------

Co-authored-by: Alberto Schiabel <jkomyno@users.noreply.github.com>
Co-authored-by: jkomyno <alberto@composio.dev>
@composio/cli@0.2.32-beta.271
2026-06-24 18:28:45 +04:00
palash-c a987990c44 Document version-placeholder project API key permission endpoints (#3631)
## Summary\n- show project API key permission endpoints with
/api/{version}/... placeholders instead of duplicating versioned rows\n-
keep proxy execute documented for direct and session proxy paths\n\n##
Verification\n- bun run lint:links from docs/\n- git diff --check
2026-06-23 10:14:28 +05:30
Alberto Schiabel e408af962a fix(py): align Python release metadata (#3634)
This PR:
- fixes
https://github.com/ComposioHQ/composio/actions/runs/27964338497/job/82754032484
- aligns `python/composio/__version__.py` with the current Python
package version `0.16.0`
- adds the missing `0.16.0` Python changelog entry for the dependency
refresh
- restores `pnpm run test:release-workflow` on `next`
2026-06-22 20:42:56 +04:00
Serhii Zghama 6a4cb542ae fix(core): resolve $ref/$defs so file flags behind a reference aren't dropped (#3566)
## Problem

Tools whose parameter schemas express their file fields through a
`$ref`/`$defs` indirection lose auto file handling: with
`dangerouslyAllowAutoUploadDownloadFiles` enabled, a `file_uploadable`
input behind a `$ref` is never staged (the local path is forwarded as-is
and the backend rejects it), and the `format: "path"` hint never reaches
the model.

`GMAIL_GET_ATTACHMENT` is the canonical shape — its parameters nest the
file flag two `$ref` hops deep:

```
data → $ref → #/$defs/GetAttachmentResponse → file → $ref → #/$defs/FileDownloadable   (file_downloadable: true)
```

This is the TypeScript-SDK counterpart of #3506 (the Python side is
handled separately in #3545).

Two coupled causes defeat reference resolution:

1. **`$defs` is dropped on parse.** `ParametersSchema`
(`src/types/tool.types.ts`) is a strict `z.object` that never declared
`$defs`/`definitions`, so `ToolSchema.parse` stripped the root
definition block off every tool. Each nested `$ref` was then dangling
and unresolvable for *all* downstream consumers — providers that pass
`inputParameters` straight to the model (e.g. `OpenAIProvider`) and the
file modifier alike. (`JSONSchemaPropertySchema` already accepts both
keywords; the root did not.)
2. **The file modifier never dereferences.** `transformProperties`,
`schemaHasFileProperty`, and the upload/download hydration recurse
`properties`/`anyOf`/`oneOf`/`allOf`/`items` but skip `$ref`, so a flag
reachable only through a reference is invisible to the walk.

## Solution

- Add `$defs`/`definitions` to `ParametersSchema` so the root definition
block survives parsing and `$ref` pointers stay resolvable.
- Dereference `inputParameters`/`outputParameters` in `FileToolModifier`
(node runtime) before walking, via the existing `dereferenceJsonSchema`
helper in `'sentinel'` mode — the same mode `MastraProvider` already
uses. Tools that ship a `$ref` without a matching `$defs` target (#3307)
degrade to a permissive object instead of throwing, exactly as today.

No new dependencies; `dereferenceJsonSchema` already exists and is
exercised by the Mastra provider. The edge (`workerd`) modifier is
unchanged — its upload/download paths already throw as unsupported.

## Testing

- `pnpm typecheck` — clean.
- `pnpm test` (core) — 926 passing, including new cases:
- `$ref`-indirected `file_uploadable` is marked `format: "path"` by
`modifyToolSchema`.
- `fileUploadModifier` stages a file whose flag is reachable only via
`$ref`/`$defs`.
- a `$ref` with no matching `$defs` target degrades gracefully (no
throw).
- root `$defs` survives `ToolSchema.parse` and nested `$ref` pointers
remain intact.
- Provider suites unaffected: `mastra` (51), `openai` (29), `vercel`
(10), `anthropic` (19) all green.

---------

Co-authored-by: jkomyno <alberto@composio.dev>
2026-06-22 19:32:07 +04:00
komai fd88b2e5b7 fix(core): drop manual Content-Length in S3 upload PUT for compat with strict undici dispatcher (refs #3548) (#3549)
## Summary

Remove the manual `Content-Length` header from the presigned-URL PUT in
`uploadFileToS3`. Node.js's built-in fetch (undici) computes
`Content-Length` from the request body itself and rejects any
user-supplied value with `InvalidArgumentError: invalid content-length
header` (`UND_ERR_INVALID_ARG`), which surfaces as `TypeError: fetch
failed`.

The result is that **`composio.files.upload()` has been broken on Node
22+ since the feature was introduced** (commit 84d4381 / PR #1670,
shipped in `0.1.29` on 2025-06-19), which in turn broke every
`file_uploadable` connector tool that relies on the BE staging path —
Instagram media (`INSTAGRAM_POST_IG_USER_MEDIA` with `image_file`),
Drive uploads, Slack file shares, etc.

Fixes #3548.

## What changed

```diff
   const uploadResponse = await fetch(signedURL, {
     method: 'PUT',
     body: uploadBuffer,
     headers: {
       'Content-Type': mimeType,
-      'Content-Length': contentBytes.length.toString(),
     },
   });
```

I left a short comment above the call so this isn't reintroduced by a
future "let's set the headers explicitly" cleanup.

## Why this works

Per the WHATWG Fetch spec, `Content-Length` is computed by the
implementation from the body. undici enforces this strictly: a
user-supplied `Content-Length` is treated as an invalid argument and the
request is rejected before any bytes leave the client. Dropping the
manual header lets fetch derive the correct value from `uploadBuffer`
automatically.

## Verification

End-to-end against `@composio/core@0.10.0` with this change applied to a
patched `node_modules`:

- `composio.files.upload({ file, toolSlug: 'INSTAGRAM_UPLOAD_FILE',
toolkitSlug: 'INSTAGRAM' })` with a ~760 KB JPEG → R2 PUT succeeds,
`s3key` returned.
- Downstream `INSTAGRAM_POST_IG_USER_MEDIA` with `image_file: { name,
mimetype, s3key }` posts successfully.
- Reproduces the original failure (`TypeError: fetch failed` /
`InvalidArgumentError: invalid content-length header`) on
`@composio/core@0.10.0` without this change on Node v24.16.0 and v22.x.

Sequence observed in production logs (matching threads in our DB):

| step | image arg | result |
| --- | --- | --- |
| before fix | `image_file: { maisonai_file: ... }` → staged via
`composio.files.upload` | **ERROR** (`invalid content-length header`) |
| after fix | same | **SUCCESS** (R2 PUT → `s3key` →
`INSTAGRAM_POST_IG_USER_MEDIA` → publish) |

## Notes

- The bug went unnoticed for ~12 months. From a quick scan of the test
suite and issue tracker, the existing file-upload tests use very small
payloads where undici sometimes lets a manual `Content-Length` through;
anything close to a real-world image consistently fails. Might be worth
a regression test with a non-trivial payload, but I left that out of
this PR to keep the diff minimal.
- Happy to add a regression test if maintainers prefer.

## References

- Issue: #3548
- Affected file: `ts/packages/core/src/utils/fileUtils.node.ts`
- Introducing commit: 84d4381 (PR #1670)
- WHATWG Fetch — forbidden request headers:
https://fetch.spec.whatwg.org/#forbidden-request-header
- undici: https://github.com/nodejs/undici
2026-06-22 19:05:36 +04:00
Alberto Schiabel a423a799c4 chore(py): refresh Python dependencies (#3627)
Refreshes the Python SDK's core + provider dependency ranges and uv
locks to the **newest cutoff-compatible** versions, and makes the locks
self-consistent.

## What changed
- Bumps core + provider dependency ranges (`pyproject.toml` /
`setup.py`) and regenerates all three uv locks (root, `openai`,
`claude_agent_sdk`) to the newest available versions.
- Keeps `composio-client==1.41.0` (the current newest, released
2026-06-19).
- Caps `crewai>=0.134.0,<0.135.0`: crewai 1.x requires
`pydantic>=2.11.9,<2.13`, which conflicts with composio core's
`pydantic>=2.13.4`. Staying on crewai 0.x keeps the newest pydantic for
everything else; the provider only uses `crewai.tools.BaseTool`, which
is unaffected.
- Drops the one-shot `--exclude-newer` cutoff that had been recorded in
the lock `[options]` but was not backed by any `[tool.uv]` config — it
broke `uv lock --check` and held packages a few releases behind newest.
- Pins nox-installed tools/stubs in `noxfile.py` to the matching newest
versions.

## Resolution result
- Root lock: **161 upgrades, 0 downgrades** vs `next`.
- Provider locks: **0 downgrades** vs `next` (openai +14,
claude_agent_sdk +29).

## Verification
- `uv lock --check` — clean on all three locks.
- `uv run --frozen --all-packages pytest python/tests/test_imports.py` —
8/8 passing.
- `uv run --frozen nox -s chk` — ruff clean + mypy 0 issues across 80
source files.

Supersedes https://github.com/ComposioHQ/composio/pull/3622 (which was
opened from a fork).
2026-06-22 18:23:17 +04:00
Palash Kala 9f09b13f71 Document version-placeholder permission endpoints 2026-06-22 18:21:20 +05:30
Alberto Schiabel 4b76dbf70d fix(core): remove deprecated auth-config uuid field from V3 responses (#3633)
Replacement for #3528, preserving @lingala-composio's original commit,
so CI can run from a same-repository branch.

The original PR is from a fork. The TypeScript E2E workflow reads
`COMPOSIO_API_KEY`, `COMPOSIO_BASE_URL_STAGING`,
`COMPOSIO_USER_API_KEY`, `OPENAI_API_KEY`, and `ANTHROPIC_API_KEY` from
repository secrets, and GitHub does not expose those secrets to fork PR
workflow runs. That is why #3528's E2E checks failed with empty env
values before exercising this SDK change.

## What & Why

The Composio platform is removing the deprecated V1/V2 UUID-mirror
fields from V3 API responses. The TypeScript SDK read and re-exposed the
auth-config `uuid`, which was a deprecated mirror of the canonical
nanoid `id`. This stops the SDK from depending on the removed field.

## Changes

- Drop `uuid: authConfig.uuid` from
`transformAuthConfigRetrieveResponse`.
- Remove `uuid` from `AuthConfigRetrieveResponseSchema`.
- Update AuthConfigs tests and fixtures to match the new contract.
- Keep top-level `expectedInputFields` unchanged; only the deprecated
nested bag was removed.

## Verification

- `git diff --check origin/next...HEAD`
- `pnpm --filter @composio/core test AuthConfigs`

---------

Co-authored-by: lingala-composio <rahul.lingala@composio.dev>
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-22 14:28:44 +04:00
Lingala 9914c90412 docs: remove non-existent alias parameter from initiate-to-link migration guide (#3540)
## What

Removes the incorrect `alias` references from the initiate-to-link
migration guide
(`docs/content/docs/auth-configuration/migrating-initiate-to-link.mdx`).

## Why

The `alias` parameter does **not** exist on either method:
- TS: `composio.connectedAccounts.link()` /
`composio.connectedAccounts.initiate()`
- Python: `composio.connected_accounts.link()` /
`composio.connected_accounts.initiate()`

This was verified against the SDK source and the generated client. The
doc should not claim the parameter exists. Real alias/label support may
be added later; this change only corrects the docs for now.

## Changes

- Dropped `alias` from the sentence: `` `callback_url` / `callbackUrl`
works the same way on both methods. ``
- Deleted the `` | `alias` | ✓ | ✓ | `` row from the comparison table.

No other content changed (`callback_url`, `allow_multiple`, `config`
rows are intact).

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-22 14:01:26 +04:00
Abhishek Patil d7cfd3c09c docs: add Notion connection expiry FAQ (#3601)
## Summary
- Add a Notion FAQ entry for connection expiry reasons.
- Cover user-initiated revocation/removal from Notion workspace
connections.
- Cover the same-user/same-OAuth-app reconnection pattern that can leave
older Composio-managed connections with stale tokens.

## Validation
- `git diff --check`
- `bun run scripts/validate-links.ts` could not run because `bun install
--frozen-lockfile` fails with existing docs lockfile drift: `lockfile
had changes, but lockfile is frozen`.
2026-06-21 00:54:58 +04:00
Alberto Schiabel 23f9053804 chore(ts): clean up dependencies and bump toolchain (#3623)
This PR:

- consolidates and bumps TypeScript/npm dependencies across the
monorepo, docs, examples, and e2e fixtures — no runtime behavior changes
- **cleanup:** remove the unused `ansis` dependency from `@composio/cli`
(`picocolors` is the actual color lib), drop the dead `uuid` catalog
entry, catalog `dotenv` + `@types/bun` and repoint drifting examples/e2e
onto them, and replace `chalk` with `picocolors` in `@composio/core`
(smaller, ESM, already used by the CLI)
- **TypeScript 6:** bump `typescript` `5.9 → 6.0.3` everywhere (catalog,
CLI test fixtures, docs); drop vestigial `declaration`/`outDir` from the
provider `tsconfig.json`s to fix the TS 6 `rootDir` regression
(`TS6059`); add `ignoreDeprecations: "6.0"` in docs for the `baseUrl`
deprecation
- **toolchain:** `tsdown 0.18 → 0.22.3`, `vitest` + `@vitest/ui →
4.1.9`, `publint → 0.3.21`, `wrangler → 4.101.0` (each the latest
version within the 3-day `minimumReleaseAge` gate)
- **Effect + hono:** `effect 3.21.3`, `@effect/cli 0.75.2`,
`@effect/platform 0.96.1`, `platform-bun 0.90.0`, `platform-node-shared
0.60.0`, `language-service 0.86.2`, `@effect/vitest 0.29.0`, `hono
4.12.25`; pin the Effect peer cohort
(`printer`/`printer-ansi`/`typeclass`/`rpc`/`sql`/`cluster`/`experimental`/`workflow`)
as `@composio/cli` devDeps so the auto-installed peers resolve
coherently, and bump `@cloudflare/workers-types` to satisfy `wrangler`'s
peer
- changesets: `@composio/cli` patch (ansis removal) and `@composio/core`
patch (chalk → picocolors)
- verified: `build`, `typecheck` (tsgo + real `tsc` 6.0.3), and local
tests (excluding e2e) all pass
@composio/cli@0.2.32-beta.270
2026-06-21 00:54:27 +04:00
Alberto Schiabel 24e647fa16 test(ts/e2e): cover claude agent sdk on node current (#3620)
This PR:
- builds on top of https://github.com/ComposioHQ/composio/pull/3495
- adds a Node.js `current` e2e suite for `@composio/claude-agent-sdk`
- exercises the packaged provider through Claude Agent SDK
`createSdkMcpServer` / `query()` with a deterministic local tool
- forwards `ANTHROPIC_API_KEY` through Turbo, Docker e2e env
passthrough, and the Node e2e workflow
2026-06-20 02:08:34 +04:00
Alberto Schiabel f3dd9343e6 fix(docs): preserve inline API paths in generated SDK reference (#3619)
## Summary
The TypeScript SDK reference generator (`generate-docs.ts`) strips every
`api/vN/...` substring from JSDoc descriptions to keep raw endpoint
paths out
of user-facing docs. The blanket regex also strips paths that live
**inside
intentional inline-code spans**, mangling them.

Concretely, `ConnectedAccounts.initiate()`'s JSDoc:

> The legacy `` `POST /api/v3/connected_accounts` `` endpoint that this
method …

currently renders in the generated reference as:

> The legacy `` `POST `` endpoint that this method …

— content lost and an unclosed code span. (Visible today in

`docs/content/reference/sdk-reference/typescript/connected-accounts.mdx`.)

## Fix
In `extractDescription`, split the text on inline-code spans and only
strip
bare API paths **outside** backticks; deliberate route references inside
code
spans are left intact. The path regex is also tightened to stop at
code-span
and punctuation boundaries (`` ` ``, `)`, `,`, `.`, `;`).

The single affected reference page is regenerated in the same commit.

## Verification
- `pnpm --filter @composio/core generate:docs` → only
`connected-accounts.mdx`
changes, restoring the full `` `POST /api/v3/connected_accounts` ``
span.

## Context
Salvaged from the now-superseded #3518 — re-derived against the current
generator. The rest of #3518 (drift-gate workflow, regenerated MDX,
generator
rework) is obsoleted by the post-merge auto-regeneration workflow
(`generate-sdk-docs.yml`) and #3613.
2026-06-20 00:22:46 +04:00
Alberto Schiabel cbbad15126 fix(ts): support Zod 4 custom tool schemas (#3495)
## Summary

Stacked on #3494.

This PR tightens the SDK's Zod boundary now that the TypeScript packages
are moving to the newer Node/toolchain baseline. The main issue was
asymmetric Zod support: `@composio/json-schema-to-zod` already supports
projects with Zod 3 and Zod 4 by generating schemas through `zod/v3`,
but custom tools converted schemas in the opposite direction through
`zod-to-json-schema` only. With a bare Zod 4 `z.object(...)`, that path
degraded to an empty JSON Schema.

## What changed

- Added a shared core helper for Zod schema -> JSON Schema conversion.
- Supports both `zod/v3` schemas and Zod 4 schemas via `z.toJSONSchema`.
- Converts custom-tool input schemas in Zod 4 input mode, so defaulted
fields stay optional in the generated JSON Schema.
- Uses the shared helper in both custom-tool entrypoints:
`createCustomTool(...)` and legacy
`composio.tools.createCustomTool(...)`.
- Updates custom-tool types so Zod 4 schemas infer their `execute` input
type while keeping the session context parameter required for
context-using tools.
- Exposes `jsonSchemaToZodShape` through the narrow
`@composio/core/utils/json-schema` subpath.
- Switches the Claude Agent SDK provider to use that core subpath
instead of depending directly on `@composio/json-schema-to-zod` or
converting to a full Zod object and casting `.shape` out of it.
- Adds patch changesets for `@composio/core` and
`@composio/claude-agent-sdk`.

## Review hardening

Follow-up fixes from a deeper pass over the new conversion boundary:

- **Fixes a Zod 3 regression in the v3/v4 discriminator.** The detector
keyed on `_def.type` being defined, but Zod 3 stores the element schema
there for `z.array()` / `z.promise()` — so a Zod 3 array/promise
`outputParams` was misrouted into `z.toJSONSchema` and crashed with
`Cannot read properties of undefined (reading 'def')`. It now
discriminates on `_def.type` being a string literal (Zod 4) versus a
`ZodType` object (Zod 3), with a regression test.
- **Mirrors input/output mode on the Zod 3 path.** The `io` mode was
applied to the Zod 4 converter but dropped on the Zod 3 branch; it now
maps onto `zod-to-json-schema`'s `pipeStrategy`/`effectStrategy` so
`.default()` / `.transform()` / `.pipe()` schemas serialize consistently
across both runtimes. Added a v3/v4 input-mode parity test.
- **Fails loudly on a missing named definition** instead of returning
the wrapper document, which downstream silently degraded into an empty
object schema.
- **Replaces broad `as never` casts** in the Claude Agent SDK provider
with a single concrete `tool()` signature — this sidesteps the SDK's
deep-instantiation error while keeping the handler's real argument type.
- **Trims now-dead code** from the custom-tool schema types and
conversion path.

## Verification

- `mise exec -- pnpm --filter @composio/core test` (933 passing)
- `mise exec -- pnpm --filter @composio/claude-agent-sdk test --
--runInBand` (17 passing)
- `mise exec -- pnpm --filter @composio/core build` (publint + attw
clean, emits `@composio/core/utils/json-schema`)
- `mise exec -- pnpm --filter @composio/claude-agent-sdk exec tsc
--noEmit --skipLibCheck`
- `mise exec -- pnpm --filter @composio/claude-agent-sdk build` (publint
+ attw clean)
- `mise exec -- pnpm install --frozen-lockfile`
- `git diff --check`

Note: `mise exec -- pnpm --filter @composio/core typecheck` still fails
on the existing `src/utils/pusher.ts` `ChannelAuthorizationHandler` type
mismatch. This PR does not touch that file; the core build and full core
unit suite pass.
2026-06-19 23:42:37 +04:00
Alberto Schiabel 31449b25a3 fix(release): register @composio/ts-builders in root workspaces (#3617)
This PR:

- fixes the `next TS SDK Release` workflow failing at `changeset
version` with `Found changeset drop-commonjs-entrypoints for package
@composio/ts-builders which is not in the workspace`
- adds `ts/packages/ts-builders` to the `workspaces` array in the root
`package.json`

`@manypkg/get-packages` (used by changesets) detects the root
`workspaces` field and treats the repo as a yarn workspace, so it
ignores `pnpm-workspace.yaml` entirely. `@composio/ts-builders` was only
registered in `pnpm-workspace.yaml`, so changesets never saw it. The
mismatch was latent until PR #3494 became the first changeset to bump
that package.

Verified `pnpm exec changeset status` now succeeds and lists all 16
packages, including `@composio/ts-builders`.
2026-06-19 23:39:58 +04:00
Alberto Schiabel 025a657597 feat(ts): drop CommonJS support (#3494)
This PR moves the TypeScript SDK support floor to the latest Node.js 22
release and uses that as the point where we stop carrying custom
CommonJS compatibility machinery. The e2e runtime coverage now exercises
the latest Node 22, Node 24, and Node 25 lines, so the SDK is tested
against the minimum supported version and the newer runtimes users are
likely to adopt next.

Because the SDK packages are still on `0.x`, the accompanying changeset
uses `minor` bumps while calling out that this is a breaking change
inside the existing 0.x line.

It also moves pnpm under mise on this Node 22 layer. That belongs here,
not in #3493, because the pinned `pnpm@10.28.2` requires Node.js
`>=22.13`. Removing Corepack is intentional: Node.js documents that
Corepack is no longer distributed starting with Node.js v25, so relying
on `corepack enable` would keep a toolchain dependency that is already
on the way out of the Node distribution.

## What changed

- Pins the local/toolchain Node.js floor to `22.22.3` in `mise.toml`,
`mise.lock`, `toolchain-versions.json`, and root `devEngines`.
- Pins pnpm in `mise.toml` as `"npm:pnpm" = "10.28.2"` and makes mise
the single source of truth for the pnpm version. Removes the root
`packageManager` / `devEngines.packageManager` Corepack pin entirely
(rather than keeping a second copy of the version that could drift) and
removes stale `packageManager` metadata from real TS packages/examples
and generators.
- Sets `dangerouslyDisablePackageManagerCheck: true` in `turbo.jsonc` so
Turbo discovers pnpm from `pnpm-lock.yaml` instead of requiring a
`packageManager` field. Without this, Turbo fails workspace resolution
(`Could not resolve workspaces -> Missing 'packageManager' field`),
which is the only reason the field would otherwise need to stay.
- Replaces `corepack enable` in the shared setup action with
mise-managed pnpm. The E2E Docker images install bun + pnpm directly
from `mise.toml`/`mise.lock` (with
`dangerouslyDisablePackageManagerCheck`-style separation: Node/Deno stay
on the base image as the test matrix axis and are disabled via
`MISE_DISABLE_TOOLS` so mise does not shadow them; the tool binaries are
symlinked into `/usr/local/bin`). No `BUN_VERSION`/`PNPM_VERSION` build
args are threaded from the host anymore, and bun+pnpm now carry
`mise.lock` checksum verification.
- Extends the install-time toolchain check to validate pnpm against mise
alongside Bun.
- Sets the Node E2E matrix and install fallback checks to `22.22.3`,
`24.16.0`, and `25.9.0`.
- Makes TS package builds ESM-only: `tsdown` now emits `.mjs` / `.d.mts`
only and uses the ATTW `esm-only` profile.
- Removes explicit `require` / `.cjs` / `.d.cts` package export paths
and internal import mappings from the public TS SDK packages.
- Marks public TS SDK packages as `type: module` where they were missing
it.
- Replaces the remaining runtime `require('pusher-js')` with dynamic ESM
import.
- Deletes the legacy CJS example.
- Reintroduces `node/cjs-basic` as a modern Node `require(esm)` interop
E2E: it verifies `require('@composio/core')` works through Node's native
ESM loader on Node 22, 24, and 25 while resolving to `dist/index.mjs`,
not a `.cjs` artifact.
- Removes `.cjs` / `.cts` handling from example validation and CLI
project-language detection.
- Updates provider scaffolding so newly generated providers are
ESM-only.
- Adds a minor changeset warning that CommonJS callers can only rely on
Node's native `require(esm)` interop and that custom CommonJS
compatibility machinery is gone.

## Bundled behavior changes

Two changes here are technically independent of the CommonJS removal but
ride along because they touch the same files and ship in the same
release cut. Calling them out explicitly so they are not missed in
review:

- **`PusherUtils` realtime channel auth (`@composio/core`).** Replacing
the runtime `require('pusher-js')` with a dynamic ESM `import()` was
done alongside conforming `channelAuthorization` to pusher-js's typed
`customHandler(params, callback)` contract. The previous `(authOptions)
=> Promise` shape did not match pusher-js's actual calling convention —
it read `endpoint`/`headers`/`params` off an argument that pusher-js
never passes — so this also fixes that latent mismatch. New unit tests
(`ts/packages/core/test/utils/pusher.test.ts`) cover the auth request
shape (endpoint, `x-api-key` header, JSON `socket_id`/`channel_name`
body) and the success / invalid-JSON / network-failure callback paths.
- **CLI meta-tool slug list (`@composio/cli`).** Drops
`COMPOSIO_UPSERT_RECIPE` and `COMPOSIO_GET_RECIPE` from
`META_TOOL_SLUG_LIST` in `tools-executor.ts`; `@composio/client`
alpha.74 removed those slugs from the `SessionExecuteMetaParams['slug']`
union. The list is declared `satisfies
ReadonlyArray<SessionExecuteMetaParams['slug']>`, so this is enforced at
compile time (`pnpm typecheck`) — keeping the stale slugs would be a
type error — and needs no separate runtime test.

## Verification

- Verified latest Node 22/24/25 releases from the official Node dist
index: `22.22.3`, `24.16.0`, `25.9.0`
(https://nodejs.org/dist/index.json).
- Verified Node docs state Corepack is no longer distributed starting
with Node.js v25:
https://nodejs.org/download/release/v22.22.3/docs/api/corepack.html
- `mise exec -- pnpm --version` -> `10.28.2`
- `mise exec -- pnpm install --frozen-lockfile`
- `mise exec -- bun run ts/scripts/pre-install/check-toolchain.ts`
- `mise exec -- pnpm --filter @e2e-tests/utils typecheck`
- `mise exec -- pnpm --filter @e2e-tests/node-cjs-basic typecheck`
- `mise exec -- pnpm --filter @e2e-tests/node-cjs-basic test:e2e:node`
- `mise exec -- pnpm --filter @e2e-tests/node-esm-basic typecheck`
- `mise exec -- pnpm --filter @composio/cli typecheck`
- `mise exec -- pnpm --filter @composio/cli test -- --runInBand`
- `mise exec -- pnpm --filter @composio/core typecheck`
- `mise exec -- pnpm --filter @composio/core exec vitest run
test/utils/pusher.test.ts`
- `mise exec -- pnpm run build:packages`
- `mise exec -- turbo run build --dry-run` resolves all workspace
packages with no root `packageManager` field (pnpm discovered from
`pnpm-lock.yaml`).
- `mise exec -- pnpm --filter @composio/cli exec vitest run
test/src/services/project-environment-detector.test.ts`
- `mise exec -- pnpm exec prettier --check ...`
- `docker build -f ts/e2e-tests/_utils/Dockerfile.node --build-arg
NODE_VERSION=24.16.0 -t composio-e2e-node:misecheck .` (also
`Dockerfile.deno` with `DENO_VERSION=2.6.7 NODE_MAJOR=22`) — both build
green; runtime resolves Node/Deno from the base image and pnpm 10.28.2 /
bun 1.3.10 from mise.
- `docker manifest inspect node:24.16.0-slim`
- `docker manifest inspect node:25.9.0-slim`
- `bash -n ts/scripts/create-provider.sh && git diff --check`
- `ruby -e "require 'yaml';
YAML.load_file('.github/workflows/ts.test-e2e.yml')"`
- Tracked example validation in a clean temporary tree: `Validated 21
example packages.`
@composio/cli@0.2.32-beta.269
2026-06-19 22:22:17 +04:00
Alberto Schiabel 5f004ffbfe fix(cli): drop recipe meta-tool slugs removed from @composio/client (#3615)
This PR:

- cherry-picks the CLI fix from
https://github.com/ComposioHQ/composio/pull/3494 so `next` is unblocked
independently of that larger ESM-only PR
- fixes the `@composio/cli#build` typecheck failure on `next` (`TS2322`
in `ts/packages/cli/src/services/tools-executor.ts`) that is currently
breaking the **TS SDK Release** workflow
- `@composio/client` alpha.74
(https://github.com/ComposioHQ/composio/pull/3609) removed
`COMPOSIO_UPSERT_RECIPE` and `COMPOSIO_GET_RECIPE` from
`SessionExecuteMetaParams['slug']`, but `META_TOOL_SLUG_LIST` (declared
`satisfies ReadonlyArray<SessionExecuteMetaParams['slug']>`) still
listed them, so the build no longer type-checked
- adds a `@composio/cli` patch changeset

Verified locally: `pnpm --filter @composio/cli typecheck` passes.
@composio/cli@0.2.32-beta.268
2026-06-19 22:11:49 +04:00
sdkrelease[bot] 3b4168a203 docs: update TypeScript SDK reference from source (#3613)
## Summary
Auto-generated TypeScript SDK reference docs from
`ts/packages/core/src/`.

Regenerates pages at `docs/content/reference/sdk-reference/typescript/`
to reflect changes in the core package's public API (new methods,
updated signatures, changed types).

Co-authored-by: jkomyno <12381818+jkomyno@users.noreply.github.com>
Co-authored-by: Alberto Schiabel <jkomyno@users.noreply.github.com>
2026-06-19 16:39:50 +00:00
sdkrelease[bot] 0b1e478476 docs: update Python SDK reference from source (#3612)
## Summary
Auto-generated Python SDK reference docs from `python/composio/`.

Regenerates pages at `docs/content/reference/sdk-reference/python/` to
reflect changes in the Python package's public API (new methods, updated
signatures, changed types).

Co-authored-by: jkomyno <12381818+jkomyno@users.noreply.github.com>
2026-06-19 20:39:21 +04:00
Alberto Schiabel a0bef5d986 chore(deps): bump composio client SDKs (TS alpha.74, Py 1.41.0) (#3609)
This PR:

- bumps the TS catalog `@composio/client` from `0.1.0-alpha.72` to
`0.1.0-alpha.74` (published from ComposioHQ/composio-base-ts#84) and
refreshes `pnpm-lock.yaml`
- bumps the Python `composio-client` pin from `1.39.0` to `1.41.0`
(published from ComposioHQ/composio-base-py#69)
- adds a patch changeset for `@composio/core` and `@composio/cli` so the
client bump actually ships in the next release

## Context

Neither client is auto-bumped in this repo — there is no
Stainless→consumer bot, and Dependabot does not touch the pnpm
`catalog:` pin (TS) or the exact `composio-client==` pin (Py), so these
were a manual catch-up. The Python `1.41.0` PyPI publish initially
failed with a `403 Forbidden` (stale `PYPI_TOKEN`); it was re-run
successfully before this bump, so `1.41.0` is live on PyPI.
2026-06-19 18:42:59 +04:00
Alberto Schiabel b346272572 chore(ci): use OIDC for TS npm releases, add needed attributes to package.json (#3611)
This PR:

- configures the TS release workflow to request GitHub Actions OIDC ID
tokens
- runs the TS release publish path on Node 24.17.0 so npm supports
trusted publishing
- leaves a TODO to centralize that release runtime in `mise.toml` after
https://github.com/ComposioHQ/composio/pull/3494 lands
- removes the long-lived `NPM_TOKEN` `.npmrc` setup before `changeset
publish`
- adds npm package support metadata (`repository.url`, `bugs.url`, and
`homepage`) for every public TS release workspace that Changesets can
publish
- marks `@composio/cli-local-tools` private so Changesets does not try
to publish it
@composio/llamaindex@0.9.3 @composio/mastra@0.9.3 @composio/langchain@0.9.3 @composio/google@0.9.3 @composio/core@0.11.0 @composio/openai-agents@0.9.3 @composio/cloudflare@0.9.3 @composio/cli-local-tools@0.0.5 @composio/claude-agent-sdk@0.9.3 @composio/openai@0.9.3 @composio/anthropic@0.9.3 @composio/vercel@0.9.3 @composio/cli@0.2.32-beta.267
2026-06-19 18:34:10 +04:00
Abir Taheer f6df489c0b Release: update version (#3429)
> [!WARNING]
> ## ⚠️ Breaking change — `@composio/core@0.11.0` (minor bump, pre-1.0)
>
> The legacy in-memory custom-tools registry
**`composio.tools.createCustomTool(...)` has been removed** (changeset
`44e5458`). Because `@composio/core` is pre-1.0, this ships as a
**minor** bump per semver convention — but it **is breaking**: any code
calling `composio.tools.createCustomTool(...)` will fail to compile/run
after upgrading. Consumers pinned to `^0.10.0` will **not** auto-upgrade
to `0.11.0` and must opt in explicitly.

### Migration: use Tool Router custom tools

Custom tools are now standalone factories bound to a **Tool Router
session**, instead of being registered into an in-memory registry on the
`composio.tools` namespace.

**Before (removed):**

```ts
// ❌ No longer available in 0.11.0
const tool = composio.tools.createCustomTool({ /* ... */ });
```

**After — a standalone tool (no auth):**

```ts
import { Composio, experimental_createTool } from '@composio/core';
import { z } from 'zod';

const composio = new Composio();

const grep = experimental_createTool('GREP', {
  name: 'Grep Search',
  description: 'Search for patterns in files',
  inputParams: z.object({ pattern: z.string(), path: z.string() }),
  execute: async (input) => ({ matches: [] }),
});

// Bind the custom tool(s) to a Tool Router session
const session = await composio.create(userId, {
  experimental: { customTools: [grep] },
});
```

**After — a tool that extends a Composio toolkit (inherits that
toolkit's auth):**

```ts
const getImportantEmails = experimental_createTool('GET_IMPORTANT_EMAILS', {
  name: 'Get Important Emails',
  description: 'Fetch high-priority emails',
  extendsToolkit: 'gmail',
  inputParams: z.object({ limit: z.number().default(10) }),
  execute: async (input, ctx) => {
    // ctx.execute() returns the standard { data, error, logId } shape
    const result = await ctx.execute('GMAIL_SEARCH', { query: 'is:important' });
    return { emails: result.data };
  },
});

const session = await composio.create(userId, {
  experimental: { customTools: [getImportantEmails] },
});
```

**After — grouping related tools into a custom toolkit:**

```ts
import { experimental_createToolkit } from '@composio/core';

const devTools = experimental_createToolkit('DEV_TOOLS', {
  name: 'Dev Tools',
  description: 'Local developer utilities',
  tools: [grep], // tools here must NOT set `extendsToolkit`
});

const session = await composio.create(userId, {
  experimental: { customToolkits: [devTools] },
});
```

> Notes:
> - `experimental_createTool` / `experimental_createToolkit` are also
available from the dedicated `@composio/core/experimental` entry point.
> - Tool slugs are auto-prefixed with `LOCAL_` when exposed to the agent
(e.g. `GREP` → `LOCAL_GREP`; inside a toolkit, `DEV_TOOLS` + `GREP` →
`LOCAL_DEV_TOOLS_GREP`).
> - These APIs are intentionally namespaced `experimental_*` — they are
not yet stable and may change.

---

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/core@0.11.0

### Minor Changes

- a94715f: Forward `userId` when creating trigger instances so trigger
2FA flows can verify connected account ownership.
- 44e5458: Remove the legacy `composio.tools.createCustomTool(...)`
in-memory registry API. Use Tool Router custom tools via
`experimental_createTool`, `experimental_createToolkit`, and
`composio.create(..., { experimental: { customTools, customToolkits }
})` instead.

### Patch Changes

- 22a9171: Defer telemetry batch and error sends so instrumentation does
not wait for telemetry network requests before returning SDK results or
rethrowing SDK errors.
- 93b67e8: Fix automatic file upload/download substitution for file
schemas that accept either a single file or a list of files.

The file modifier now selects composed-schema branches by runtime value
shape, so `anyOf(file, array<file>)` uploads or downloads each file when
the tool receives a list while preserving existing single-file behavior.

- b69cef1: Tolerate dangling `$ref` pointers in tool schemas the
Composio API ships without a matching `$defs` entry. Some toolkits (e.g.
`GMAIL_FETCH_EMAILS`) emit `outputParameters` with `"$ref":
"#/$defs/FetchEmailsResponse"` while never declaring a top-level `$defs`
block. After the strict resolver shipped with the previous Mastra fix,
this caused `composio.tools.get(...)` to throw
`JsonSchemaRefResolutionError` upfront, making every Gmail / Slack /
Google-Calendar tool unusable through `MastraProvider`. The SDK now
degrades the unresolvable branch to a permissive object schema and
surfaces a single observability warning per `(toolSlug, ref)` pair
instead of crashing.
- `dereferenceJsonSchema` accepts a new optional second argument `{
onUnresolved?: 'throw' | 'sentinel'; onReplace?: (ref, reason) => void
}`. Default behavior is unchanged (`'throw'`) — first-party /
custom-tool schemas with a typo'd `$ref` still surface as a hard error.
Pass `'sentinel'` to replace unresolved branches with the cycle-break
sentinel (`{ type: 'object', additionalProperties: true }`) that the
resolver already uses for `$ref` cycles. The replaced sentinel carries a
default `description` hint so LLMs consuming the wrapped tool's schema
get an in-band signal that the branch is opaque; a caller-provided
`description` sibling overrides the default (Draft 2020-12
sibling-keyword merge). Safety caps (`MAX_REF_CHAIN_DEPTH`,
`MAX_NODE_DEPTH`) keep throwing in both modes. New
`UnresolvedRefStrategy`, `UnresolvedRefReason`, and
`DereferenceJsonSchemaOptions` type exports.
- `MastraProvider.wrapTool` opts both `inputParameters` and
`outputParameters` into `'sentinel'` mode and emits one `logger.warn`
per `(toolSlug, ref)` pair via the provider-scoped dedup `Set`.
User-controlled segments in the warning (`tool.slug`, `toolkit.slug`,
`ref`) are `JSON.stringify`d to neutralize embedded newlines / ANSI
escapes / control bytes that could otherwise forge log lines (CWE-117).
A matching one-shot telemetry event
(`composio.mastra.wrapTool.danglingRef`) fires next to the warn so the
Composio team has aggregate visibility into which toolkits are affected;
the event respects `COMPOSIO_DISABLE_TELEMETRY=true`.
- The `telemetry` instance from `@composio/core` is now publicly
re-exported alongside `logger`, so providers can emit aggregate signals
without reaching into the package's internals.
- Resolvable `$defs` / `definitions` continue to be inlined exactly as
before — no regression in the type-info preservation contract introduced
by the previous Mastra fix.

- 1ba66ca: Fix `tools.execute` (and `tools.get` / `tools.list`) failing
with a `ZodError` for every tool from an MCP-backed toolkit (e.g.
`granola_mcp`, `apify_mcp`, `tavily_mcp`).

MCP toolkits don't declare an output schema, and the Composio API
serializes that as `output_parameters: {}`. The SDK's `ParametersSchema`
required `{ type: 'object', properties: {...} }`, so
`transformToolCases` rejected the response and
`getRawComposioToolBySlug` — called by `execute` and the list path —
threw.

The SDK now normalizes empty (`{}`), `null`, and missing
`input_parameters` / `output_parameters` payloads to `undefined` before
validation. `outputParameters` was already declared `.optional()` in the
public `Tool` type, so this preserves the contract: "undefined means no
declared schema." Tools that _do_ declare a schema continue to be
validated strictly.

  No public API change; no toolkit allow-list.

- ce4b213: fix(providers): normalize string tool-call arguments across
all providers

Models occasionally emit tool-call arguments as a JSON string instead of
an
object (most visibly with `COMPOSIO_MULTI_EXECUTE_TOOL` on the Vercel AI
SDK),
  which broke downstream validation with errors like
  `tool_use.input: Input should be a valid dictionary`.

`@composio/core` now exposes a single `normalizeToolArguments` helper,
and every
provider routes model-supplied arguments through it. Object payloads
pass
through unchanged, JSON strings are parsed, empty/`null` payloads become
`{}`,
  and anything that cannot resolve to an object throws a typed
`ComposioInvalidToolArgumentsError` instead of a raw `SyntaxError` or a
silently
forwarded malformed string. This replaces the inconsistent per-provider
guards
  that previously existed only in vercel, cloudflare and openai-agents.
## @composio/cli-local-tools@0.0.5

### Patch Changes

- Updated dependencies [22a9171]
- Updated dependencies [93b67e8]
- Updated dependencies [b69cef1]
- Updated dependencies [1ba66ca]
- Updated dependencies [a94715f]
- Updated dependencies [ce4b213]
- Updated dependencies [44e5458]
  - @composio/core@0.11.0
## @composio/anthropic@0.9.3

### Patch Changes

- ce4b213: fix(providers): normalize string tool-call arguments across
all providers

Models occasionally emit tool-call arguments as a JSON string instead of
an
object (most visibly with `COMPOSIO_MULTI_EXECUTE_TOOL` on the Vercel AI
SDK),
  which broke downstream validation with errors like
  `tool_use.input: Input should be a valid dictionary`.

`@composio/core` now exposes a single `normalizeToolArguments` helper,
and every
provider routes model-supplied arguments through it. Object payloads
pass
through unchanged, JSON strings are parsed, empty/`null` payloads become
`{}`,
  and anything that cannot resolve to an object throws a typed
`ComposioInvalidToolArgumentsError` instead of a raw `SyntaxError` or a
silently
forwarded malformed string. This replaces the inconsistent per-provider
guards
  that previously existed only in vercel, cloudflare and openai-agents.
## @composio/claude-agent-sdk@0.9.3

### Patch Changes

- ce4b213: fix(providers): normalize string tool-call arguments across
all providers

Models occasionally emit tool-call arguments as a JSON string instead of
an
object (most visibly with `COMPOSIO_MULTI_EXECUTE_TOOL` on the Vercel AI
SDK),
  which broke downstream validation with errors like
  `tool_use.input: Input should be a valid dictionary`.

`@composio/core` now exposes a single `normalizeToolArguments` helper,
and every
provider routes model-supplied arguments through it. Object payloads
pass
through unchanged, JSON strings are parsed, empty/`null` payloads become
`{}`,
  and anything that cannot resolve to an object throws a typed
`ComposioInvalidToolArgumentsError` instead of a raw `SyntaxError` or a
silently
forwarded malformed string. This replaces the inconsistent per-provider
guards
  that previously existed only in vercel, cloudflare and openai-agents.
## @composio/cloudflare@0.9.3

### Patch Changes

- ce4b213: fix(providers): normalize string tool-call arguments across
all providers

Models occasionally emit tool-call arguments as a JSON string instead of
an
object (most visibly with `COMPOSIO_MULTI_EXECUTE_TOOL` on the Vercel AI
SDK),
  which broke downstream validation with errors like
  `tool_use.input: Input should be a valid dictionary`.

`@composio/core` now exposes a single `normalizeToolArguments` helper,
and every
provider routes model-supplied arguments through it. Object payloads
pass
through unchanged, JSON strings are parsed, empty/`null` payloads become
`{}`,
  and anything that cannot resolve to an object throws a typed
`ComposioInvalidToolArgumentsError` instead of a raw `SyntaxError` or a
silently
forwarded malformed string. This replaces the inconsistent per-provider
guards
  that previously existed only in vercel, cloudflare and openai-agents.
## @composio/google@0.9.3

### Patch Changes

- ce4b213: fix(providers): normalize string tool-call arguments across
all providers

Models occasionally emit tool-call arguments as a JSON string instead of
an
object (most visibly with `COMPOSIO_MULTI_EXECUTE_TOOL` on the Vercel AI
SDK),
  which broke downstream validation with errors like
  `tool_use.input: Input should be a valid dictionary`.

`@composio/core` now exposes a single `normalizeToolArguments` helper,
and every
provider routes model-supplied arguments through it. Object payloads
pass
through unchanged, JSON strings are parsed, empty/`null` payloads become
`{}`,
  and anything that cannot resolve to an object throws a typed
`ComposioInvalidToolArgumentsError` instead of a raw `SyntaxError` or a
silently
forwarded malformed string. This replaces the inconsistent per-provider
guards
  that previously existed only in vercel, cloudflare and openai-agents.
## @composio/langchain@0.9.3

### Patch Changes

- ce4b213: fix(providers): normalize string tool-call arguments across
all providers

Models occasionally emit tool-call arguments as a JSON string instead of
an
object (most visibly with `COMPOSIO_MULTI_EXECUTE_TOOL` on the Vercel AI
SDK),
  which broke downstream validation with errors like
  `tool_use.input: Input should be a valid dictionary`.

`@composio/core` now exposes a single `normalizeToolArguments` helper,
and every
provider routes model-supplied arguments through it. Object payloads
pass
through unchanged, JSON strings are parsed, empty/`null` payloads become
`{}`,
  and anything that cannot resolve to an object throws a typed
`ComposioInvalidToolArgumentsError` instead of a raw `SyntaxError` or a
silently
forwarded malformed string. This replaces the inconsistent per-provider
guards
  that previously existed only in vercel, cloudflare and openai-agents.
## @composio/llamaindex@0.9.3

### Patch Changes

- ce4b213: fix(providers): normalize string tool-call arguments across
all providers

Models occasionally emit tool-call arguments as a JSON string instead of
an
object (most visibly with `COMPOSIO_MULTI_EXECUTE_TOOL` on the Vercel AI
SDK),
  which broke downstream validation with errors like
  `tool_use.input: Input should be a valid dictionary`.

`@composio/core` now exposes a single `normalizeToolArguments` helper,
and every
provider routes model-supplied arguments through it. Object payloads
pass
through unchanged, JSON strings are parsed, empty/`null` payloads become
`{}`,
  and anything that cannot resolve to an object throws a typed
`ComposioInvalidToolArgumentsError` instead of a raw `SyntaxError` or a
silently
forwarded malformed string. This replaces the inconsistent per-provider
guards
  that previously existed only in vercel, cloudflare and openai-agents.
## @composio/mastra@0.9.3

### Patch Changes

- b69cef1: Tolerate dangling `$ref` pointers in tool schemas the
Composio API ships without a matching `$defs` entry. Some toolkits (e.g.
`GMAIL_FETCH_EMAILS`) emit `outputParameters` with `"$ref":
"#/$defs/FetchEmailsResponse"` while never declaring a top-level `$defs`
block. After the strict resolver shipped with the previous Mastra fix,
this caused `composio.tools.get(...)` to throw
`JsonSchemaRefResolutionError` upfront, making every Gmail / Slack /
Google-Calendar tool unusable through `MastraProvider`. The SDK now
degrades the unresolvable branch to a permissive object schema and
surfaces a single observability warning per `(toolSlug, ref)` pair
instead of crashing.
- `dereferenceJsonSchema` accepts a new optional second argument `{
onUnresolved?: 'throw' | 'sentinel'; onReplace?: (ref, reason) => void
}`. Default behavior is unchanged (`'throw'`) — first-party /
custom-tool schemas with a typo'd `$ref` still surface as a hard error.
Pass `'sentinel'` to replace unresolved branches with the cycle-break
sentinel (`{ type: 'object', additionalProperties: true }`) that the
resolver already uses for `$ref` cycles. The replaced sentinel carries a
default `description` hint so LLMs consuming the wrapped tool's schema
get an in-band signal that the branch is opaque; a caller-provided
`description` sibling overrides the default (Draft 2020-12
sibling-keyword merge). Safety caps (`MAX_REF_CHAIN_DEPTH`,
`MAX_NODE_DEPTH`) keep throwing in both modes. New
`UnresolvedRefStrategy`, `UnresolvedRefReason`, and
`DereferenceJsonSchemaOptions` type exports.
- `MastraProvider.wrapTool` opts both `inputParameters` and
`outputParameters` into `'sentinel'` mode and emits one `logger.warn`
per `(toolSlug, ref)` pair via the provider-scoped dedup `Set`.
User-controlled segments in the warning (`tool.slug`, `toolkit.slug`,
`ref`) are `JSON.stringify`d to neutralize embedded newlines / ANSI
escapes / control bytes that could otherwise forge log lines (CWE-117).
A matching one-shot telemetry event
(`composio.mastra.wrapTool.danglingRef`) fires next to the warn so the
Composio team has aggregate visibility into which toolkits are affected;
the event respects `COMPOSIO_DISABLE_TELEMETRY=true`.
- The `telemetry` instance from `@composio/core` is now publicly
re-exported alongside `logger`, so providers can emit aggregate signals
without reaching into the package's internals.
- Resolvable `$defs` / `definitions` continue to be inlined exactly as
before — no regression in the type-info preservation contract introduced
by the previous Mastra fix.

- ce4b213: fix(providers): normalize string tool-call arguments across
all providers

Models occasionally emit tool-call arguments as a JSON string instead of
an
object (most visibly with `COMPOSIO_MULTI_EXECUTE_TOOL` on the Vercel AI
SDK),
  which broke downstream validation with errors like
  `tool_use.input: Input should be a valid dictionary`.

`@composio/core` now exposes a single `normalizeToolArguments` helper,
and every
provider routes model-supplied arguments through it. Object payloads
pass
through unchanged, JSON strings are parsed, empty/`null` payloads become
`{}`,
  and anything that cannot resolve to an object throws a typed
`ComposioInvalidToolArgumentsError` instead of a raw `SyntaxError` or a
silently
forwarded malformed string. This replaces the inconsistent per-provider
guards
  that previously existed only in vercel, cloudflare and openai-agents.
## @composio/openai@0.9.3

### Patch Changes

- ce4b213: fix(providers): normalize string tool-call arguments across
all providers

Models occasionally emit tool-call arguments as a JSON string instead of
an
object (most visibly with `COMPOSIO_MULTI_EXECUTE_TOOL` on the Vercel AI
SDK),
  which broke downstream validation with errors like
  `tool_use.input: Input should be a valid dictionary`.

`@composio/core` now exposes a single `normalizeToolArguments` helper,
and every
provider routes model-supplied arguments through it. Object payloads
pass
through unchanged, JSON strings are parsed, empty/`null` payloads become
`{}`,
  and anything that cannot resolve to an object throws a typed
`ComposioInvalidToolArgumentsError` instead of a raw `SyntaxError` or a
silently
forwarded malformed string. This replaces the inconsistent per-provider
guards
  that previously existed only in vercel, cloudflare and openai-agents.
## @composio/openai-agents@0.9.3

### Patch Changes

- ce4b213: fix(providers): normalize string tool-call arguments across
all providers

Models occasionally emit tool-call arguments as a JSON string instead of
an
object (most visibly with `COMPOSIO_MULTI_EXECUTE_TOOL` on the Vercel AI
SDK),
  which broke downstream validation with errors like
  `tool_use.input: Input should be a valid dictionary`.

`@composio/core` now exposes a single `normalizeToolArguments` helper,
and every
provider routes model-supplied arguments through it. Object payloads
pass
through unchanged, JSON strings are parsed, empty/`null` payloads become
`{}`,
  and anything that cannot resolve to an object throws a typed
`ComposioInvalidToolArgumentsError` instead of a raw `SyntaxError` or a
silently
forwarded malformed string. This replaces the inconsistent per-provider
guards
  that previously existed only in vercel, cloudflare and openai-agents.
## @composio/vercel@0.9.3

### Patch Changes

- ce4b213: fix(providers): normalize string tool-call arguments across
all providers

Models occasionally emit tool-call arguments as a JSON string instead of
an
object (most visibly with `COMPOSIO_MULTI_EXECUTE_TOOL` on the Vercel AI
SDK),
  which broke downstream validation with errors like
  `tool_use.input: Input should be a valid dictionary`.

`@composio/core` now exposes a single `normalizeToolArguments` helper,
and every
provider routes model-supplied arguments through it. Object payloads
pass
through unchanged, JSON strings are parsed, empty/`null` payloads become
`{}`,
  and anything that cannot resolve to an object throws a typed
`ComposioInvalidToolArgumentsError` instead of a raw `SyntaxError` or a
silently
forwarded malformed string. This replaces the inconsistent per-provider
guards
  that previously existed only in vercel, cloudflare and openai-agents.
## @composio/cli@0.2.32

### Patch Changes

- Updated dependencies [22a9171]
- Updated dependencies [93b67e8]
- Updated dependencies [b69cef1]
- Updated dependencies [1ba66ca]
- Updated dependencies [a94715f]
- Updated dependencies [ce4b213]
- Updated dependencies [44e5458]
  - @composio/core@0.11.0
  - @composio/cli-local-tools@0.0.5

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
@composio/cli@0.2.32-beta.266
2026-06-19 17:12:38 +04:00
Alberto Schiabel 82896858ec fix(docs): retry 429s in data sync scripts and lower concurrency (#3608)
This PR:

- adds a shared `fetchWithRetry` helper for the docs data-sync scripts
that retries `429` and transient 5xx responses, honoring `Retry-After`
(with jitter) and falling back to exponential backoff
- routes every request in `generate-toolkits.ts` and
`generate-meta-tools.ts` through it, so the `Docs - Update Data`
workflow rides out the staging rate limit (2000 req/min) instead of
hard-failing
- lowers toolkit fetch `batchSize` 10 → 5 (~30 → ~15 concurrent
requests) to soften burst pressure on the rate limit
- caps retry attempts so CI still fails fast when the backend is
genuinely down
- fixes the current `429 Too Many Requests` failure in `Generate meta
tools reference`, which inherited the rate-limit window exhausted by the
high-volume `generate-toolkits.ts` run
- verified with `bun run types:check` and an offline retry/backoff
behavior test (real end-to-end run needs the staging key in CI: `gh
workflow run docs-update-data.yml`)
- follow-up (separate PR): reduce per-toolkit request volume in
`generate-toolkits.ts` — left out here because it needs consumer and
search-quality validation
2026-06-18 20:37:42 +04:00
Alberto Schiabel d7d5d46f4d fix(ts/e2e): stabilize Tool Router e2e tests (#3605)
This PR:

- addresses the Mastra Tool Router E2E timeout seen in
https://github.com/ComposioHQ/composio/actions/runs/27758637694/job/82126898492
- addresses the Cloudflare Tool Router AI failure seen in
https://github.com/ComposioHQ/composio/actions/runs/27759741357/job/82130692480
- addresses the follow-up Cloudflare basic timeout seen in
https://github.com/ComposioHQ/composio/actions/runs/27760548665/job/82133483582
- uses the existing `TIMEOUTS.LLM_LONG` live-LLM budget for both Mastra
Tool Router zod-v3 and zod-v4 suites
- raises the HTTP MCP connection-phase timeout from Mastra's implicit 3s
default to 15s in both zod-v3 and zod-v4 suites
- keeps the Cloudflare AI test's `Output.object({ karma })` structured
output and validates the returned `response.karma`
- asserts that `HACKERNEWS_GET_USER` was called and that
`response.karma` equals the structured MCP tool output
- removes the extra Cloudflare `prepareStep` steering and
`findNumberProperty` extraction helper
- avoids explicit `@ai-sdk/mcp` HTTP client close calls in workerd
because the close path aborts the pending stream and Vitest reports it
as unhandled
- gives the live Cloudflare HackerNews compatibility test a 30s budget
while leaving the fast smoke tests on Vitest's default timeout
- fixes the zod-v3 test label so it reports `zod 3` instead of `zod 4`

Verification:

- `./ts/e2e-tests/_utils/node_modules/.bin/tsc --noEmit -p
ts/e2e-tests/runtimes/node/mastra-tool-router-zod-v3/tsconfig.json`
- `./ts/e2e-tests/_utils/node_modules/.bin/tsc --noEmit -p
ts/e2e-tests/runtimes/node/mastra-tool-router-zod-v4/tsconfig.json`
- `pnpm exec vitest run -t "should connect to MCP server"` from
`ts/e2e-tests/runtimes/cloudflare/cf-workers-tool-router-ai`
- `pnpm exec tsc --noEmit --target es2022 --lib es2022 --module es2022
--moduleResolution Bundler --resolveJsonModule
--allowSyntheticDefaultImports --strict --skipLibCheck --types
@cloudflare/workers-types src/index.ts` from
`ts/e2e-tests/runtimes/cloudflare/cf-workers-tool-router-ai`
- `pnpm exec vitest run -t "should fetch HackerNews user pg
successfully"` from `ts/e2e-tests/runtimes/cloudflare/cf-workers-basic`
- `pnpm exec vitest run` from
`ts/e2e-tests/runtimes/cloudflare/cf-workers-basic`
- `pnpm exec prettier --check
ts/e2e-tests/runtimes/cloudflare/cf-workers-basic/test/platform.spec.ts`
- `pnpm exec prettier --check
ts/e2e-tests/runtimes/cloudflare/cf-workers-tool-router-ai/src/index.ts
ts/e2e-tests/runtimes/cloudflare/cf-workers-tool-router-ai/test/tool-router-ai.spec.ts
ts/e2e-tests/runtimes/node/mastra-tool-router-zod-v3/e2e.test.ts
ts/e2e-tests/runtimes/node/mastra-tool-router-zod-v4/e2e.test.ts`
- `git diff --check`

CI:

- `E2E Test Typescript SDK` passed on
https://github.com/ComposioHQ/composio/actions/runs/27768379357

Note: the full Cloudflare AI test was not run locally because this
checkout's local `OPENAI_API_KEY` is invalid; CI has the repo secret for
that path.
2026-06-18 19:01:02 +04:00
samvitjatia f032cd5f69 docs: clarify HubSpot scope configuration (#3603)
## Summary
- Tighten the HubSpot toolkit FAQ into five customer-facing questions
instead of many scope-adjacent entries
- Clarify HubSpot scope category matching: Composio `scopes` maps to
HubSpot required/conditionally required, and `optional_scopes` maps to
HubSpot optional
- Document managed-auth limitations, custom-auth examples,
Create/Get/Update Auth Config API usage, reconnect behavior, and grouped
troubleshooting checks
- Add guidance for HubSpot's unverified-app warning and Composio's
active app approval work

## Verification
- Confirmed live HubSpot auth config API responses expose
`credentials.scopes` and `credentials.optional_scopes`
- `git diff --check` passed
- `bun run scripts/validate-links.ts` could not run locally because docs
dependencies are missing: `fumadocs-mdx/bun`
2026-06-18 18:00:30 +05:30
sjd9021 77d883238a docs: clarify HubSpot scope configuration 2026-06-18 17:54:40 +05:30
jkomyno 0720b760e2 fix(docs): stabilize SDK reference auto PR checks 2026-06-18 16:13:17 +04:00
Alberto Schiabel eeaac651d8 chore(py): document pending releases (#3583)
This PR:
- documents the pending Python `0.14.0` and `0.15.0` releases in
`python/CHANGELOG.md`
- aligns `python/composio/__version__.py` with `python/pyproject.toml`
at `0.15.0`
- adds a release guard so Python package/provider versions, runtime
version, and changelog entries cannot drift silently
- leaves Python release tags and PyPI publishing untouched; `py@0.14.0`
should still be published before `py@0.15.0`
py@0.15.0
2026-06-18 12:33:42 +04:00
Alberto Schiabel 95843b37e3 fix(docs): use app token for data sync PRs (#3599)
This PR:

- adds the same `actions/create-github-app-token` setup used by the SDK
docs generator
- checks out the repository with the generated app token
- passes the app token to `peter-evans/create-pull-request`
- uses the app token for the optional reviewer request
- fixes the current `Docs - Update Data` failure where `CI_BOT_TOKEN`
cannot authenticate the git push for `docs/auto-update-data`
- verified with `go run
github.com/rhysd/actionlint/cmd/actionlint@latest
.github/workflows/docs-update-data.yml` and `git diff --check`
2026-06-17 20:36:57 +04:00
Alberto Schiabel 3374b477a6 fix(docs): simplify staging data sync URLs (#3596)
This PR:

- simplifies `COMPOSIO_BASE_URL_STAGING` handling by stripping optional
`/api/v3` or `/api/v3.1` suffixes before deriving both docs API
endpoints
- removes the URL-shape branching that rejected the current staging
secret
- keeps the production backend guard so the update-data workflow does
not use `https://backend.composio.dev`
- uses `CI_BOT_TOKEN` for `peter-evans/create-pull-request` and reviewer
requests because `GITHUB_TOKEN` cannot create pull requests in this repo
- verified with `go run
github.com/rhysd/actionlint/cmd/actionlint@latest
.github/workflows/docs-update-data.yml`, `git diff --check`, and shell
URL derivation checks
2026-06-17 18:42:50 +04:00
jkomyno 2724126199 fix(docs): normalize staging data sync URLs 2026-06-17 18:37:28 +04:00
palash-c 0026d50f94 docs: pin Changelog directly under Overview in API reference sidebar (#3595)
## What
Move the **Changelog** entry in the API Reference sidebar so it sits
**immediately below Overview** (second item from the top), instead of
after **Errors**.

## Why
Requested placement — Changelog should be pinned right under Overview at
the top of the Reference nav for visibility.

## How
The Changelog node is injected programmatically in
`app/(home)/reference/(v31)/layout.tsx` (it's not a `meta.json` page).
Previously it was inserted at `errorsIdx + 1`; now it's inserted at
`overviewIdx + 1`, with a safe fallback to position 1 if "Overview"
isn't found.

Before: `Overview → Authentication → Rate Limits → Errors → Changelog →
API Reference → …`
After: `Overview → Changelog → Authentication → Rate Limits → Errors →
API Reference → …`

Only affects the v3.1 (default) Reference layout; the v3 layout doesn't
inject a Changelog node.

## Verification
- `bun run types:check` passes.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-17 18:01:50 +04:00
Alberto Schiabel 87464bf2ad fix(docs): use staging endpoints for data sync (#3591)
This PR:

- configures `docs-update-data.yml` to source docs data from
`COMPOSIO_BASE_URL_STAGING`
- fails fast when the staging base URL is missing or does not include
`/api/v3`
- derives v3 and v3.1 OpenAPI URLs from the staging secret so the job
does not fall back to production
- updates the generated data-sync PR copy to say OpenAPI specs are
fetched from staging
- quotes `$GITHUB_OUTPUT` redirects so `actionlint` stays clean
- verified with `go run
github.com/rhysd/actionlint/cmd/actionlint@latest
.github/workflows/docs-update-data.yml`, `git diff --check`, and shell
endpoint derivation checks
2026-06-17 17:46:39 +04:00
Alberto Schiabel eba6c6d7ef fix(release): keep provider peer bumps range-aware (#3582)
This PR:
- prevents the open Changesets release PR from promoting provider
packages to `1.0.0` when `@composio/core` gets a minor bump that still
satisfies their peer range
- points Changesets at `next`, matching the active TypeScript release
branch and workflow trigger
- enables `onlyUpdatePeerDependentsWhenOutOfRange` so peer dependents
only major-bump when the new dependency version leaves their declared
range
- adds a release workflow guard that runs Changesets against a fixture
and verifies `@composio/core@0.10.0` -> `0.11.0` keeps
`@composio/openai` on `0.9.3`
- leaves https://github.com/ComposioHQ/composio/pull/3429 to regenerate
after this lands on `next`
2026-06-16 16:04:25 +04:00
Anshu Garg 56e0d781f3 fix(triggers): handle V3 envelope in realtime subscribe path [SUP-392] (#3567)
## Summary

`triggers.subscribe()` crashes with `KeyError: 'nanoId'` on the **first
event** for any project configured with webhook version **V3**. The
realtime (Pusher) channel now delivers the modern V3 envelope
(snake_case: `metadata.trigger_id` / `connected_account_id` /
`auth_config_id`, with no top-level `nanoId`), but the realtime parser
(`TriggerSubscription._parse_payload`) only understood the **legacy**
envelope and accessed `data["metadata"]["nanoId"]` directly — so the
very first inbound frame raises inside the Pusher `_on_message` callback
and the registered handler is never invoked.

The SDK already knows how to normalize the V3 envelope — it does so on
the webhook path (`_normalize_v3_payload`) — that logic was simply never
wired into the realtime path.

This has affected the realtime subscribe path for V3 projects since the
V3 trigger payload format was introduced; webhook-version V1/V2 projects
are unaffected (they still receive the legacy realtime envelope).

## Changes

- Extract the V3 → `TriggerEvent` normalization into a shared
module-level helper (`_build_trigger_event_from_v3`) plus an envelope
detector (`_is_v3_envelope`); the webhook path's `_normalize_v3_payload`
now delegates to it, so webhook and realtime share one source of truth.
- `TriggerSubscription._parse_payload` now detects the V3 envelope and
normalizes it, and keeps the existing legacy mapping for V1/V2 payloads.
- Harden `_parse_payload`: unknown/malformed frames are logged and
skipped (return `None`) instead of raising, so a single bad frame can no
longer tear down an active subscription.
- Add tests covering V3 realtime parsing, legacy realtime parsing, and
malformed-frame handling.

## Type of change
- [x] Bug fix
- [ ] New feature
- [ ] Refactor/Chore
- [ ] Documentation
- [ ] Breaking change

## How Has This Been Tested?

- `ruff check` + `ruff format` (config/ruff.toml) — clean.
- `uv run pytest tests/test_triggers.py` — **52 passed** (49 existing +
3 new).
- New tests:
- `test_parse_payload_v3_realtime_envelope` — a V3 realtime frame parses
to a `TriggerEvent` (no `KeyError`).
- `test_parse_payload_legacy_envelope` — V1/V2 legacy frame still parses
correctly.
- `test_parse_payload_malformed_returns_none` — bad/partial frames are
skipped, not raised.

## Checklist
- [x] I have read the Code of Conduct and this PR adheres to it
- [x] I ran linters/tests locally and they passed
- [ ] I updated documentation as needed
- [x] I added tests or explain why not applicable
- [ ] I added a changeset if this change affects published packages

## Additional context

The realtime envelope is identical in shape to the V3 webhook envelope,
so the shared normalizer keeps the two delivery channels consistent. No
public API changes.

---------

Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Co-authored-by: jkomyno <alberto@composio.dev>
Co-authored-by: Alberto Schiabel <jkomyno@users.noreply.github.com>
2026-06-16 15:39:23 +04:00
Alberto Schiabel 08f7072110 fix(ci): make CLI releases reliably ship binary assets (#3515)
## Summary

Permanently stops the recurring *"release published with zero assets →
install/upgrade 404s"* outage
(https://github.com/ComposioHQ/composio/issues/3408,
https://github.com/ComposioHQ/composio/issues/3269; regressions of
https://github.com/ComposioHQ/composio/issues/2625 and
https://github.com/ComposioHQ/composio/issues/1820 — 3 of the last 5
stable releases shipped empty).

**Root cause:** a concurrent-writer race. On a CLI version bump,
`changesets/action` creates an empty `@composio/cli@x.y.z` GitHub
Release in seconds, then the slower `build-cli-binaries.yml` fails its
`gh release create` because the release already exists — so binaries
never attach.

> 🥞 **Stacked on #3415** (`pi/exclude-cli-ts-release-42161920`), which
removes the *second writer* (changesets no longer creates CLI releases).
Review/merge #3415 first; this PR targets that branch. This PR hardens
the now-sole writer so a *partial* build can't publish either, and fixes
the monitoring that hid the failure.

## What changed (`build-cli-binaries.yml` + canary)

- **Draft → verify → publish.** The release is built as a **draft**,
then a gate asserts all 6 canonical assets are present **and** `state ==
"uploaded"` (loud `::error::` + fail otherwise), and only the final step
flips it to published. Drafts fire no `release: published` event and are
excluded from `/releases/latest`, so no install.sh / Homebrew / redirect
consumer can observe an incomplete release.
- **`fail-fast: false`** on the build matrix → a single platform failure
can never publish a partial set (`needs.build.result` is `success` only
if all legs pass).
- **Per-tag job-level `concurrency`** so re-runs / quick pushes can't
interleave uploads on the same tag, without serializing unrelated betas.
- **Beta-safe:** `--prerelease` is set on the draft so betas stay
prereleases through the publish flip.
- **`promote-stable` guard** uses `gh release view --json isDraft` (the
REST tags endpoint 404s on drafts) to resume an existing draft but
refuse an already-published tag.
- **Least privilege:** workflow defaults to `contents: read`; only the
release job opts up to `contents: write`.
- **Canary fix** (`cli.install-health-check.yml`): install the newest
stable **pinned** tag (`npm view @composio/cli version`) instead of the
asset-aware no-arg flow, which self-heals to the last good release and
kept the canary green through every outage.

## Idempotency note

Re-running a run that failed **before publish** is safe (reuse draft +
`--clobber`). An already-**published** tag is refused, not mutated — by
design.

## Testing

- Extended `test/release-workflow.test.ts` (run via `pnpm
test:release-workflow`) to lock in: draft→verify→publish ordering,
`fail-fast: false`, per-tag concurrency, preserved `--prerelease`, and
the pinned-tag canary. ✅ passes.
- `shellcheck` clean on the new `run:` scripts; YAML validated.
`actionlint` runs in CI.
- Runtime verification of the full green path happens on the next
release CI run.

## Out of scope (deferred to their own PRs)

Per reviewer consensus, these are real but *not this bug*: a per-release
npm↔GitHub asset auditor (needs a grace window), the Homebrew trigger
constraint (folds into #3355), `composio upgrade` missing-asset back-off
(https://github.com/ComposioHQ/composio/issues/3269), and a rollback
runbook.

---------

Co-authored-by: Rahul Tarak <cryogenicplanet@gmail.com>
@composio/cli@0.2.32-beta.265
2026-06-16 15:07:23 +04:00
XananasX 632757ec60 chore(ts/packages/core): add repository, bugs, and homepage metadata (#3573)
## Summary

Adds missing npm support metadata to `ts/packages/core/package.json` for
the `@composio/core` package:

- **`repository`**: adds full object with `type`, `url`, and `directory`
(monorepo package path)
- **`bugs.url`**: points to
`https://github.com/ComposioHQ/composio/issues`
- **`homepage`**: points to the package README in the repository

## Verification

```sh
npm view @composio/core@0.10.0 repository bugs homepage
# Currently returns empty for all three fields
```

No runtime code, dependencies, tests, or build configuration are
changed.

---------

Co-authored-by: XananasX7 <xananasandy@gmail.com>
Co-authored-by: Alberto Schiabel <jkomyno@users.noreply.github.com>
Co-authored-by: jkomyno <alberto@composio.dev>
2026-06-16 13:48:45 +04:00
Alberto Schiabel a9b948bac2 fix(ci): use app token for SDK docs PRs (#3577)
This PR:
- fixes
https://github.com/ComposioHQ/composio/actions/runs/27606982132/job/81621371312
- mints the existing release-bot GitHub App token in both SDK docs jobs
- passes the App token to checkout and `peter-evans/create-pull-request`
- uses the same App token for the reviewer-assignment `gh pr edit` step
- keeps the TypeScript and Python docs generation commands unchanged

Verification:
- `git diff --check`
- `ruby -e \"require 'yaml';
YAML.load_file('.github/workflows/generate-sdk-docs.yml'); puts 'yaml
ok'\"`
- `bash .github/scripts/check-action-repos.sh`
- confirmed `RELEASE_BOT_APP_ID` and `RELEASE_BOT_APP_PRIVATE_KEY` exist
in repo secrets
2026-06-16 13:24:11 +04:00
Anshu Garg a94715f577 feat(sdk): forward user_id on triggers.create for trigger 2FA (#3576)
## What

`triggers.create(userId/user_id, ...)` already accepts a user id and
uses it to resolve the connected account, but **dropped it** when
building the `trigger_instances.upsert` body. With [2FA for
triggers](https://linear.app/composio/issue/PLEN-2580) on the backend,
2FA-enabled projects need `user_id` on the upsert to verify the pinned
connected account belongs to the caller's user.

This forwards `user_id` to upsert in **both SDKs**:

- **TS** (`ts/packages/core/src/models/Triggers.ts`): adds `user_id` to
the upsert params via a `& { user_id?: string }` bridge.
- **Python** (`python/composio/core/models/triggers.py`): forwards
`user_id` via the client's supported `extra_body` escape hatch.

Both bridges exist only until `@composio/client` / `composio-client`
regenerate from the updated OpenAPI spec with a native `user_id` field —
drop them then.

## Safety

Backends without trigger 2FA ignore the extra field, so this is safe to
land ahead of / alongside the backend rollout (hermes PR #10635).

## Tests

- TS: upsert-body assertion added.
- Python: `tests/test_triggers.py::test_create_with_user_id` asserts
`extra_body == {"user_id": ...}`. 49 tests pass.

Closes part of PLEN-2580 (SDK follow-up to the agreed approach).

🤖 Generated with [Claude Code](https://claude.com/claude-code)

---------

Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
Co-authored-by: jkomyno <alberto@composio.dev>
2026-06-16 13:10:37 +04:00
Alberto Schiabel ce4b213361 fix(providers): normalize string tool-call arguments across all providers (TS + Python) (#3514)
## Summary

Models — and some MCP transports — occasionally emit tool-call arguments
as a **JSON string instead of an object/dict**. The most visible trigger
is `COMPOSIO_MULTI_EXECUTE_TOOL` on the Vercel AI SDK, where streaming
fails with:

> `messages.3.content.1.tool_use.input: Input should be a valid
dictionary`

Until now only a handful of providers guarded against this, each with
its own slightly different inline check, leaving most providers
vulnerable and behaviour inconsistent across the SDK.

This PR centralizes the coercion into **one helper per language** and
routes **every** provider through it, in both the TypeScript and Python
SDKs.

Closes https://github.com/ComposioHQ/composio/issues/2406

## What changed

**TypeScript** — new `normalizeToolArguments` in `@composio/core`
(exported), used by every provider:
`vercel`, `cloudflare`, `openai-agents`, `openai` (ChatCompletions +
Responses), `anthropic`, `google`, `langchain`, `llamaindex`,
`claude-agent-sdk`, `mastra`.

**Python** — new `normalize_tool_arguments` in `composio.utils.shared`,
used by every provider:
`openai`, `openai-responses`, `anthropic`, `google`, `langchain`,
`langgraph`, `crewai`, `autogen`, `llamaindex`, `gemini`, `google-adk`,
`openai-agents`, `claude-agent-sdk`.

Shared semantics (identical in both languages):

| Input | Result |
| --- | --- |
| object / dict | returned unchanged |
| JSON string | parsed to object |
| empty / whitespace string | `{}` |
| `null` / `undefined` / `None` | `{}` |
| array, primitive, unparseable string, JSON that isn't an object |
**typed error** (`ComposioInvalidToolArgumentsError` / `InvalidParams`)
with the original parse error as cause |

The typed error replaces the previous grab-bag of behaviours: a raw
`SyntaxError`/`JSONDecodeError`, or — worse — silently forwarding a
malformed string downstream.

## Why this supersedes the open PRs

This consolidates and extends three open PRs that each addressed a slice
of the problem inconsistently. Their authors are credited as co-authors
on the relevant commits:

- **#3489** (LlamaIndex + Claude Agent SDK, TS) — @srijanarya
- **#3438** (Anthropic, Google, LangChain, TS) — @aptsalt
- **#3437** (Google ADK empty schemas + name fix, Python) —
@pragnyanramtha — its empty-`input_parameters` / missing-description
handling and the `gemini` → `google_adk` provider-name fix are folded in
here.

Compared to the three combined, this PR additionally: covers **every**
provider in **both** SDKs (not a subset of one), defines a single source
of truth instead of per-provider snippets, normalizes empty/`null`
payloads to `{}`, and raises an actionable typed error instead of
leaking `SyntaxError` or forwarding a bad string.

## Tests

- Exhaustive unit tests for both helpers (object passthrough,
JSON-string parse, empty/null → `{}`, malformed/non-object → typed
error).
- Per-provider regression tests across the touched TypeScript providers
(string path, malformed-string path, empty-payload path).
- Full `@composio/core` + touched-provider TS suites pass; `typecheck`
and `lint` clean. Python `ruff` clean and new test green.

## Changeset

Patch bump for all affected TypeScript packages (`@composio/core` + the
providers). Python follows its own versioning, so no changeset there.

---------

Co-authored-by: srijanarya <74669415+srijanarya@users.noreply.github.com>
Co-authored-by: Deepak Singh Kandari <deepaksinghkandari07@gmail.com>
Co-authored-by: Pragnyan Ramtha <pragnyanramtha@gmail.com>
2026-06-16 12:49:37 +04:00
Malay Vasa d8ec506ec8 fix docs Decimal widget loading (#3575)
## Summary
- stop loading the Decimal widget globally from the docs root layout
- load the Decimal script only when the user clicks Ask AI or uses the
shortcut
- preserve Decimal theme syncing after the widget has loaded

## Why
Slack/GSC investigation pointed at mobile CLS regressions on docs pages.
Lighthouse trace comparison isolated the layout shift to the Decimal
iframe/sidebar; blocking Decimal took /docs CLS from ~0.302 to 0, while
blocking PostHog did not change CLS.

## Validation
- bun run types:check
- bunx eslint app/layout.tsx components/ask-ai-button.tsx
components/custom-search-dialog.tsx components/decimal-widget.ts
- bun run test
- local Playwright check on http://localhost:3000/docs: no getdecimal
scripts or requests before interaction; after clicking Ask AI the
Decimal script loads and the sidebar opens

## Notes
- full `bun run lint` is still red on existing unrelated docs lint
issues on next, including @next/next/no-html-link-for-pages and
react-hooks compiler rules in other files
2026-06-15 18:10:36 -07:00
shams haroon e2e6b5974d docs: add MCP, files, and realtime routes to scoped API key permissions (#3550)
Updates the scoped project API key permissions reference with the routes
cataloged in ComposioHQ/platform#10638 (PLEN-2623):

- **Sessions** — now covers MCP server management (`/mcp/servers*`,
`/mcp/{id}`, instances), the MCP runtime transport, and the tool router
MCP transport
- **Tool execution** — adds `POST /files/upload/response` and `GET
/files/list` (file legs of tool execution)
- **Triggers** — adds the SDK/CLI realtime subscribe endpoints
(`triggers.subscribe()` / `composio triggers listen`)

Tables mirror `PROJECT_API_KEY_PERMISSION_CATALOG` as of the platform
merge.

🤖 Generated with [Claude Code](https://claude.com/claude-code)
2026-06-15 15:11:39 -07:00
shams haroon 99cfe17b18 docs: rename scoped API keys page title to "Scoped Project API Key"
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
2026-06-15 15:08:54 -07:00
Alberto Schiabel 6606c0da92 fix(ts): upgrade vitest for GHSA-5xrq-8626-4rwp (#3569)
This PR:

- closes #3502
- extracts the useful dependency and Cloudflare config slice from
https://github.com/ComposioHQ/composio/pull/3503 onto a clean `next`
branch
- upgrades `vitest` and `@vitest/ui` through the workspace catalog to
resolve the critical advisory
- switches the Mastra provider test dependency back to the catalog
- migrates the Cloudflare Worker Vitest configs to the
`cloudflareTest()` plugin API
- preserves existing `COMPOSIO_BASE_URL` bindings that were dropped in
#3503
- keeps Vitest 4 compatibility fixes scoped to constructor mocks, spy
cleanup, and temp-root project detection
- leaves Node, `mise`, release docs, and Effect catalog versions
unchanged; the commit includes @Dotify71 as `Co-authored-by`

Co-authored-by: Dushyant Acharya <dushyantacharya873@gmail.com>
@composio/cli@0.2.32-beta.264
2026-06-15 19:38:51 +04:00
Alberto Schiabel 74ce25812e fix(ci): repair CLI binary and docs sync workflows (#3568)
This PR:
- patches the Peekaboo sidecar build to rewrite the resolved
`swift-system` `AT_RESOLVE_BENEATH` Darwin guard before compiling on
GitHub macOS runners
- adds regression coverage for the `swift-system` checkout patch and
includes script tests in `@composio/cli-local-tools` Vitest
- switches the SDK docs sync workflow to
`anthropics/claude-code-action/base-action` so push-triggered automation
does not fail on unsupported event parsing
- moves Claude tool restrictions to `claude_args` and quotes
`$GITHUB_OUTPUT` writes so the workflow passes `actionlint`
- verifies the changed package and workflow with targeted tests, build,
formatting, YAML parsing, and `actionlint`
@composio/cli@0.2.32-beta.263
2026-06-15 15:27:21 +04:00
Alberto Schiabel 4fe776898a chore(toolchain): finish mise migration (#3493)
## Summary

Depends on #3492.

This completes the Phase 2 migration by removing the transitional
version-file layer and making `mise.toml` plus `mise.lock` the
repository toolchain source of truth. It also moves runtime test
matrices into `toolchain-versions.json`, so CI matrix changes are
explicit and reviewable without reintroducing `.nvmrc`, `.dvmrc`,
`.bun-version`, or `.python-version`.

The Node.js e2e matrix now starts at the latest Node 22 LTS line and
also covers the latest Node 24 and Node 25 lines. That removes Node 20
from the well-known e2e versions while keeping us covered on the
runtimes SDK users are moving toward.

## Rationale

Phase 1 introduced mise side by side with the existing version files to
keep the first PR low-risk. Phase 2 removes that compatibility layer so
there is one place to update tool versions. That avoids silent drift
between local setup, GitHub Actions, Docker E2E images, release docs,
and install-time checks.

The composite setup actions now install Node, Bun, Python, and uv
through mise by default, with explicit version overrides only where a
matrix needs them. New GitHub actions added in this PR are pinned by
release commit SHA and include the release version comment.

## What changed

- Deleted the transitional root/version files: `.nvmrc`, `.bun-version`,
`.dvmrc`, root `.python-version`, and `python/.python-version`.
- Removed `idiomatic_version_file_enable_tools` from `mise.toml` and
added a committed `mise.lock` for linux/macOS x64/arm64 tool resolution.
- Replaced `BYPASS_BUN_VERSION_CHECK` with `BYPASS_TOOLCHAIN_CHECK`, and
made Docker E2E image installs use that bypass because they receive
explicit build args instead of installing mise.
- Updated Node/Bun and Python/uv composite actions to default to mise,
remove `*-version-file` inputs, report resolved versions, and cache pnpm
after `corepack enable`.
- Centralized CI runtime matrices in `toolchain-versions.json` for TS
E2E, Python tests, and CLI npm fallback coverage.
- Updated the Node E2E matrix to `22.22.3`, `24.16.0`, and `25.9.0`,
removing Node 20 from the well-known runtime versions.
- Updated workflows, docs, E2E helpers, Dockerfiles, and release
guidance to reference `mise.toml` / `mise.lock`.

## Verification

- Verified latest Node 22/24/25 releases from the official Node dist
index: `22.22.3`, `24.16.0`, `25.9.0`
(https://nodejs.org/dist/index.json).
- `pnpm install --frozen-lockfile`
- `pnpm --filter @e2e-tests/utils typecheck`
- `pnpm --filter @e2e-tests/utils exec tsc --noEmit --target es2022
--module esnext --moduleResolution bundler --types bun
--resolveJsonModule --skipLibCheck --strict scripts/docker-build.ts`
- `bash -n ts/scripts/pre-install.sh && bun run
ts/scripts/pre-install/check-toolchain.ts && BYPASS_TOOLCHAIN_CHECK=1
bash ts/scripts/pre-install.sh`
- `pnpm exec prettier --check ...` on touched YAML/Markdown/TS/JSON
files
- `ruby -e "require \"yaml\"; ARGV.each { |f| YAML.load_file(f) }" ...`
on touched actions/workflows
- `mise lock --platform linux-x64,linux-arm64,macos-arm64,macos-x64 &&
git diff --exit-code mise.lock`
- `mise exec node@22.22.3 -- pnpm --filter @e2e-tests/utils typecheck`
- `mise exec node@22.22.3 -- pnpm --filter @e2e-tests/node-esm-basic
typecheck`
- `mise exec node@22.22.3 -- pnpm --filter @e2e-tests/node-cjs-basic
typecheck`
- `docker manifest inspect node:24.16.0-slim`
- `docker manifest inspect node:25.9.0-slim`
- `git diff --check`
2026-06-15 14:03:21 +04:00
Sarah Simionescu 382f0b1c72 Create box-integration.mdx (#3565)
Adds a hidden Box integration docs page for use as the "Add" button link
in the Box app directory submission.
2026-06-14 21:20:30 -07:00
Aaliya 938eade263 Create box-integration.mdx 2026-06-14 13:05:28 -05:00
palash-c 1124aed57a docs: MCP servers → Sessions migration guide (twoslash-fixed re-add of #3551) (#3553)
Re-adds the MCP servers → Sessions migration guide that landed in #3551
and was reverted in #3552 because the docs build broke.

**Root cause of the original break:** the docs site type-checks every TS
code block via twoslash. The standalone snippets (direct-tools preset,
`session.tools()`, `session.execute()`) referenced `composio` /
`session` without declaring them → `[2552] Cannot find name 'composio'`.
Fixed by adding a hidden `import` + `const composio` + `// ---cut---`
setup preamble to each block (the same pattern
`configuring-sessions.mdx` uses), and lifting the tools/execute examples
out of nested list bullets into their own section.

**Verified locally** against latest `next`: `bun run build` → `✓
Compiled successfully` + `✓ Generating static pages (1410/1410)`, exit
0.

Files: new
`docs/content/docs/migration-guide/mcp-servers-to-sessions.mdx` +
registered in `migration-guide/meta.json`.

🤖 Generated with [Claude Code](https://claude.com/claude-code)
2026-06-12 15:25:56 +05:30