mirror of
https://github.com/ComposioHQ/composio.git
synced 2026-09-22 11:46:35 +08:00
@e2e-tests/node-custom-tools@0.0.3
394 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 sdkrelease[bot]
|
781cee45ba |
Release: update version (#4373)
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.19.0 ### Minor Changes - |
||
|
Alberto Schiabel
|
dafe1389b1 |
chore(release): prepare Python 0.22.0 and TypeScript releases (#4563)
This PR: - bumps Python `composio` and all 13 provider packages to `0.22.0` - regenerates `uv.lock` and adds the coordinated Python and TypeScript release changelog - records the manually published `@composio/typesafe@0.1.0` as the repository baseline - replaces the original TypeSafe minor changeset with a patch release for `0.1.1`, so post-publication runtime fixes ship instead of being skipped - keeps the existing Changesets train for `@composio/core@0.19.0`, `@composio/slim@0.19.0`, and provider updates - verifies the release workflow, changesets, all 20 TypeScript package builds, 147 TypeSafe tests, 590 docs static tests, and all 28 Python distributions with Twine |
||
|
Alberto Schiabel
|
d4d306073c |
fix(sdk): save tool-only MCP updates and connection-management intent (#4512)
This PR: - closes [PLEN-3890](https://linear.app/composio/issue/PLEN-3890/fix-mcp-lifecycle-update-configuration-defects) - fixes `composio.mcp.update()` dropping parts of the requested configuration: tool-only updates (`allowedTools` without `toolkits`) sent no tools field at all, and updates with toolkits sent the create-time `custom_tools` alias, which the update endpoint never reads - inverts `manuallyManageConnections` into `managed_auth_via_composio` on update, so `manuallyManageConnections: true` no longer stores "Composio manages auth" (create and generate already inverted it) - builds the update body sparsely: each provided field is sent independently, omitted fields are left out entirely instead of being sent as `undefined` - keeps the auth config of a `{ toolkit, authConfigId }` toolkit entry in `create()` and `update()` instead of discarding it via an `else if` (Python already extracted both) - sends `allowed_tools` instead of the deprecated `custom_tools` alias from `create()` too, in both SDKs; Python previously raised `TypeError` (masked as `ValidationError`) for the removed `custom_tools` kwarg against the pinned `composio-client` 1.43.0 - adds regression coverage for both SDKs and a changeset for `@composio/core` ## Context Found by the September SDK + Composio client hackathon (Area 5, MCP lifecycle), where the two worst frictions were "successful SDK updates that do not save the requested configuration" and reversed manual connection management. The hackathon's third Area 5 finding — PATCH accepting nonexistent tool slugs — is an Apollo-side defect, fixed separately in ComposioHQ/platform#13015. `MCP.ts` and the Python `mcp.py` are identical between `next` and `main`, so this merges cleanly to the beta channel afterwards. |
||
|
Alberto Schiabel
|
62e51e838f |
chore(deps): refresh safe dependencies and Effect v4 (#4538)
## Summary Refreshes the safe TypeScript, Python, and GitHub Actions dependency surface in one maintainer-owned change. Effect 4 rc.115, Vitest 5, the vendored Effect source, CLI migrations, and agent guidance move together, while known incompatible boundaries stay pinned. The Effect v4 config schemas preserve unknown fields across `config.json` and `user_data.json` read-update-write cycles. Fixes #4535 ## Changes - Keeps Cloudflare Workers fixtures on Vitest 4 until `@cloudflare/vitest-pool-workers` supports Vitest 5. - Keeps Mastra on the Workers-compatible versions and AG2 below 1.0 because AG2 1.x no longer ships the imported `autogen` module. - Removes the unused package-level `pnpm` dependency instead of changing the repository's pinned pnpm 11 toolchain. - Migrates the Effect CLI APIs, Eve callback contract, provider peer ranges, and repository skills required by the selected upgrades. - Preserves unknown CLI settings when `config.json` and `user_data.json` are read, updated, and written back. - Uses immutable SHA pins for the refreshed Claude Code actions and adds release metadata for the affected published TypeScript packages. ## Type of change - [x] Bug fix - [ ] New feature - [x] Refactor/Chore - [x] Documentation - [ ] Breaking change ## How Has This Been Tested? - `pnpm install --frozen-lockfile` with pnpm 11.8.0 - `pnpm typecheck` - `pnpm build:packages` - `pnpm --filter @composio/cli test` — 1,400 passed, 1 skipped, including targeted persistence regressions for `config.json` and `user_data.json` - Package tests — 28 workspace tasks passed - Example typechecks/tests and all Cloudflare dry-runs - Provider compatibility, experimental/Eve, Mastra, CLI keyring, and JSON-schema Effect checks - Agent-skill validation, routing validation, Effect skill example compilation, and peer-dependency checks - All three Python `uv lock --check` runs - `nox -s tst_autogen`, `nox -s snt`, and `nox -s chk type_inference` - Production dependency audit completed with the repository's three existing ignored advisories Docker CLI E2E was not run locally because the Docker daemon is unavailable. The exact root lint command also enters the vendored Effect submodule, whose checkout does not install its `@effect/oxc/oxlint` plugin; scoped lint over the changed non-vendor files passed. ## Screenshots (if applicable) Not applicable. ## Checklist - [x] I have read the Code of Conduct and this PR adheres to it - [ ] 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 The dependency migrations are covered by the focused and workspace suites. Two targeted regression tests verify that CLI updates preserve unknown fields in `config.json` and `user_data.json`. ## Additional context The Connect client sync retains its existing `Bash(curl *)` permission while moving the removed `allowed_tools` input to `claude_args`. A separate hardening change should move logo downloads outside the model-controlled shell boundary. --- [](https://github.com/EveryInc/compound-engineering-plugin) |
||
|
Alberto Schiabel
|
4b5920bf7a |
feat(sdk): add session.ensureConnected to reconcile connection state (#4536)
This PR: - addresses the connection-readiness finding from the Sept 2026 SDK + client hackathon (area 8): `session.authorize()` always starts a new link flow, even when the session already resolves an ACTIVE connection for the toolkit — callers ended up with a pending connected account while `session.toolkits()` reported a different, active one, and nothing in the SDK reconciled the two - adds `session.ensureConnected(toolkit, options?)`: it checks the session's connection state first — an ACTIVE connection (or a no-auth toolkit) returns immediately with `wasConnected: true` and no link is created; otherwise it starts the authorization flow and waits for the new connection to become active (`timeout` option, default 60s) - keeps `authorize()` unchanged as the primitive for interactive flows that should surface the redirect URL instead of blocking - documents the `session.execute()` `account` option's runtime contract: accepted on every project, and on single-account projects the identifier must match one of the session's active connections for the toolkit (matching the API behavior after the Apollo side-fix) - adds 5 unit tests for `ensureConnected` (already-connected no-op, no-auth short-circuit, link-and-wait, pending-account relink, option validation) and a changeset Verification: `pnpm exec vitest run` in `ts/packages/core` — 1320 passed; `pnpm typecheck` (tsc + type tests) clean; `pnpm lint` clean at repo root. |
||
|
Alberto Schiabel
|
c7843d8a3a |
feat(core): return session config from session.update() (#4533)
This PR: - makes `session.update()` resolve to the updated server-side session configuration instead of `void` - exposes that configuration as `session.config` (new `ToolRouterSessionConfig` type) on sessions from `create()`, `use()` and attach, so the toolkit/tool allowlist is readable without dropping to the raw client - renames the private SDK-config member on `ToolRouterSession` to `sdkConfig`, ending the runtime name clash that made `session.config` look like the SDK's `ComposioConfig` - applies the same change to the Python `ToolRouterSession` (`config` attribute, `update()` returns it) - adds a minor changeset for `@composio/core` ## Context After `sessions.use(id)` there was no way to know the session's allowlist, and `update()` threw the response away except for `configVersion` / `preload` / `sandbox` / `warnings`. Hackathon feedback (area 8). |
||
|
shams haroon
|
aefc3ec897 |
feat(typesafe): add TypeSafe Jev provider for TypeScript and Python (#4513)
## Summary Adds TypeSafe Jev providers for TypeScript and Python that turn tool schemas and a request into a call, a partial call, or an abstention. ## What changed - adds `@composio/typesafe`, a provider for TypeSafe's Jev model. Jev has no tool calling, so `composio.tools.get()` compiles tools into typed questions and `decide` returns a `call`, a `partial` call, or an `abstain`, each with a confidence - adds `execute` for a user ID or a session: caller arguments complete a `partial`, and a tool tagged `destructiveHint` routes at a fixed floor of 0.9 and needs `confirm: true` - adds the companion helpers `shortlistTools` and `confidenceGate` (a `beforeExecute` modifier that fails closed) for use with other providers - adds `composio-typesafe`, the Python counterpart with sync and async clients; both test suites compile one shared question corpus, so both SDKs ask Jev the same questions for the same tool - registers the package in the provider-compatibility release gate, adds a `minor` changeset, the `ts/examples/typesafe` example, a Python demo, and a dedicated `py.test.yml` step - exempts only `@typesafe-ai/sdk@0.6.0` from `minimumReleaseAge` (publisher, SLSA provenance, and the absence of install scripts were checked by hand), and sets `engines.node` to `>=24.17.0` for this package because the SDK terminates the process after a handled cancellation on older Node.js releases (typesafe-ai/typesafe-sdk-js#2) ## Usage ```typescript const provider = new TypesafeProvider(); const composio = new Composio({ provider }); const toolSet = await composio.tools.get('user_123', { tools: ['GITHUB_LIST_REPOSITORY_ISSUES'] }); const decision = await provider.decide(toolSet, 'List the closed issues of ComposioHQ/composio'); if (decision.kind !== 'abstain') { // Jev binds closed-set arguments (enums, booleans, arrays of enums). Free text comes from you. await provider.execute('user_123', decision, { arguments: { owner: 'ComposioHQ', repo: 'composio' } }); } ``` ## Behavior notes - `abstain` means only that the model judged so. A failed request throws one `TypesafeApiError` whose `reason` tells rate limits, timeouts, and rejections apart, and a malformed response throws `TypesafeMalformedResponseError`. No error holds state, argument values, response content, or the SDK's own error. - Routing and the action gate see `request` only, so text in `context` cannot change which tool is picked. `contextScope: 'all'` opts out. - State is never truncated: over-budget state, unknown top-level state keys, and non-JSON values throw. - The options are `client`, `apiKey`, `model`, `thresholds`, and `contextScope`. The provider builds its client at log level `warn`, so `TYPESAFE_LOG_LEVEL=debug` cannot print request bodies. - Root-level `allOf`, `anyOf`, and `oneOf` schemas are rejected explicitly in both SDKs, including after `$ref` resolution, so composed requirements cannot silently disappear. Property-level composition remains supported as documented. - Completing a partial decision requires an own, non-`undefined` argument value in TypeScript; inherited names such as `toString` do not satisfy required arguments. Supplied `__proto__` keys are preserved as own data properties. ## Validation - 147 TypeScript provider tests and 141 Python provider tests pass. The 11 new missing-argument regression cases fail on the original implementation and pass with the fixes. - Typecheck, Oxlint, Prettier, the tsdown build with ATTW/publint, Ruff, mypy, type-inference, and release-gate checks passed locally. - All 13 opt-in live tests passed across the TypeSafe-only and Composio-backed suites against real Jev 1.13.0. These tests make decisions without executing external tools. - The actual TypeScript and Python Hacker News examples both ran end to end against production APIs: fetch tools, decide, detect the missing username, supply `pg`, and execute the read-only lookup. Both returned the live profile for `pg`. Not in this PR: the docs page, which needs the first npm publish so its snippets compile. The first npm and PyPI publishes and a `TYPESAFE_API_KEY` CI secret are manual steps. ```mermaid flowchart LR A[composio.tools.get] --> B[compile tools into questions] B --> C[decide: state + questions] C --> D{Jev answers} D -->|none fits, no action, low confidence| E[abstain] D -->|required arguments missing| F[partial] D -->|everything bound| G[call] F -->|caller arguments| H[execute] G --> H H -->|destructive tool| I[needs confirm: true] ``` |
||
|
jkomyno
|
d36048fbe7 | feat(typesafe): add TypeSafe Jev provider for TypeScript | ||
|
Alberto Schiabel
|
eccb80ef10 |
fix(cli): block SSRF in proxy binary downloads (#4511)
This PR: - closes [SEC-1179](https://linear.app/composio/issue/SEC-1179/composio-attacker-can-reach-internal-services-using-ssrf-to-steal) - routes proxy binary downloads through the core `ssrfSafeFetch` guard - requires validation-to-connection pinning and fails closed when a configured dispatcher or proxy prevents it - reapplies that requirement on every redirect hop while preserving default SDK proxy compatibility - covers direct metadata targets, configured-route bypasses, redirects, and the bundled Bun companion - verifies the full core and CLI suites plus the TypeScript workspace typecheck |
||
|
Alberto Schiabel
|
11de45889a |
fix(core): contain async Pusher subscription errors (#4448)
## Summary `PusherService.subscribe` binds `pusher:subscription_error` after the Pusher subscription call returns. `pusher-js` dispatches this event asynchronously without catching listener exceptions, so authentication, permission, server, or network subscription failures could escape as uncaught exceptions in Node applications. Fixes #4445 ## Changes - Log asynchronous Pusher subscription errors at the SDK error boundary instead of throwing from the event callback. - Add regression coverage that emits `pusher:subscription_error` after `subscribe()` resolves and verifies that it does not throw. - Add a patch changeset for the fixed `@composio/core`/`@composio/slim` package group. ## Type of change - [x] Bug fix - [ ] New feature - [ ] Refactor/Chore - [ ] Documentation - [ ] Breaking change ## How Has This Been Tested? - Node `v24.17.0` / pnpm `11.8.0` - `pnpm --filter @composio/core exec vitest run test/services/pusher.test.ts test/utils/pusher.test.ts` — 2 files, 5 tests passed - `pnpm --filter @composio/core test` — 55 test files passed; 1,289 tests passed and 2 existing tests reported expected failures; command exited successfully - `pnpm --filter @composio/core typecheck` - `pnpm lint` — passed with existing repository warnings - `pnpm validate:changesets` - `pusher-js` `v8.6.0` runtime probe confirmed that an exception thrown from a `pusher:subscription_error` listener reaches Node's `uncaughtException` handler; the regression test verifies the SDK callback no longer throws. ## Screenshots (if applicable) Not 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 This patch is intentionally limited to the live `PusherService` path. XHR timeout handling is a separate concern and is not included here. The older unreferenced `PusherUtils` helper is unchanged to keep this fix scoped to the path used by `Triggers`. |
||
|
jkomyno
|
1024d1a48c |
feat(core): add optional onSubscriptionError callback for trigger subscriptions
- PusherService.subscribe and Triggers.subscribe accept an optional onSubscriptionError callback invoked with the raw pusher pusher:subscription_error payload, giving hosts a programmatic signal for post-resolution subscription failures (previously log-only). - Exceptions thrown from the callback are contained and logged, never rethrown, so a faulty handler cannot crash the host. - The parameter is optional; existing callers are unaffected. - Document the new parameter in the TypeScript triggers reference and the subscribing-to-events guide; bump the changeset to minor for the new API surface. Applies review finding #1 from the PR #4448 review. |
||
|
jkomyno
|
334abd1e09 |
fix(core): log pusher subscription outcomes truthfully
- Log the full pusher:subscription_error payload (type, error, status) instead of a flattened String(data.error) so operators can tell auth failures from permission failures. - Log the subscription success message only when Pusher dispatches pusher:subscription_succeeded, not when subscribe() returns. - Extend regression coverage for both behaviors. Applies review findings #2 and #3 from the PR #4448 review. |
||
|
Moritz Diesing
|
876c88767c |
fix(core): normalize a missing toolkit auth field group instead of throwing
Replacing the pass-through with an eager projection changed the failure mode for
an auth config detail that omits a field group. Passing the group through left
`undefined` in place, which zod rejected as a handled validation error;
`transformToolkitAuthFieldGroup` instead reads `group.required`, so the same
response now throws a `TypeError` before validation runs and crashes
`toolkits.get()`.
Default a missing or null group, and a missing list inside a group, to empty
lists. This repo's docs pipeline already assumes that shape: the schemas in
`docs/lib/toolkit-api.ts` carry `.catch({ required: [], optional: [] })` on the
same fields. Normalizing also keeps the other group usable when only one is
absent, which is typically the one the caller asked for, where a validation
error would have returned nothing.
Reported by greptile-apps on #4411.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
||
|
Alberto Schiabel
|
84bc4c2cc0 | Merge branch 'next' into fix/toolkit-auth-field-is-secret | ||
|
Alberto Schiabel
|
dcac3e4c9c | Merge branch 'next' into fix/ts-pusher-subscription-error-boundary | ||
|
jkomyno
|
9a69683efb |
docs(core): fix tools getInput, proxyExecute, and execute examples
Correct the getInput JSDoc to pass the required text field, rewrite the proxyExecute example with the real flat parameter shape and explain that relative endpoints are appended to a base URL that may include a path, and show where to find the version to pin for tools.execute. |
||
|
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 |
||
|
CoralGarden52
|
efc2e5276d | fix(core): contain async Pusher subscription errors | ||
|
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: |
||
|
Moritz Diesing
|
e9fcbe3d89 |
fix(core): stop dropping auth field metadata from toolkit auth details
`transformToolkitRetrieveResponse` handed the two auth field groups straight
through from the raw client response. Every other key on those fields already
happens to be camelCase on the wire, but `is_secret` and `legacy_template_name`
do not, so they never matched `ToolkitAuthFieldSchema` and zod dropped them
while validating the transformed object. `auth_hint_url` was never mapped at
all.
`is_secret` is the one signal a client has for deciding whether to mask an input
when it renders its own credential form, which is what
`toolkits.getConnectedAccountInitiationFields()` exists to drive. Losing it
means the caller cannot tell an API key apart from a shop subdomain. The Python
helpers return the generated client models untouched, so they never lost these
keys.
Map the auth fields explicitly instead of passing them through, and add
`isSecret`, `legacyTemplateName` and `authHintUrl` to the schemas. Optional keys
are spread conditionally so that an absent key stays absent: assigning it
unconditionally would create an own property holding `undefined` and silently
beat a caller's fallback in `{ default: 'fallback', ...field }`.
A type-level test fails the build when the generated client grows a key in any
of the four field groups that the mapping does not list. The client declares
each group as its own interface, so both the raw field type and the test
distribute over all four; deriving from one interface alone would miss a key
added to any of the other three.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
||
|
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
|
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]
|
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
|
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. |
||
|
jkomyno
|
4e633d1fe4 | chore(changeset): record experimental dependency update | ||
|
Alberto Schiabel
|
1157faf0a1 |
fix(providers): dereference $ref/$defs before schema translation (#4288)
This PR: - resolves internal `$ref`/`$defs` in tool input schemas before translation in `langchain`, `llamaindex`, `claude-agent-sdk`, `vercel`, `google`, and `openai-agents` (`onUnresolved: 'sentinel'`) - previously `$ref`-typed properties degraded to `z.any()` — the Zod converter has no `$ref` branch — or were emitted as dangling references after the root rebuild (google, openai-agents fallback) - keeps `openai-agents`' strict-structured-outputs path untouched: OpenAI resolves `$defs`/`$ref` natively including recursion, pinned by a guard test - adds per-provider `$ref` regression suites for all six providers, including dangling-`$defs` (`GMAIL_FETCH_EMAILS`) and recursive-schema cases - adds a cross-provider contract test that fails when a new provider ships without a `$ref` classification, plus property tests for `dereferenceJsonSchema` (Python counterparts land with the Python-side fix) - changes the vendor-visible schema shape for `$ref`-using tools; changeset is `minor` ## Context The same bug was fixed locally twice before (mastra, anthropic) without surfacing the other six providers — nothing enumerated providers and asked the `$ref` question. The new contract test does exactly that, so provider #11 cannot ship unclassified. Python mirrors exist already; the Python-side provider fix follows separately. |
||
|
jkomyno
|
9447932d98 |
fix(providers): dereference $ref/$defs schemas before translation
jsonSchemaToZodSchema has no $ref branch, so a $ref node degrades to z.any() for langchain, llamaindex, claude-agent-sdk, and vercel's default path. google and openai-agents' non-strict fallback rebuild the root from properties/required, discarding $defs while dangling $ref pointers survive. Dereference internal $ref/$defs before translation in all six, using onUnresolved: 'sentinel' so a $ref into an undeclared $defs block (e.g. GMAIL_FETCH_EMAILS) degrades to a permissive schema instead of throwing. The mastra and anthropic providers already had this fix; openai-agents' strict branch is untouched since OpenAI's structured outputs support $defs/$ref natively, including recursion, and google's rebuild still drops additionalProperties/title/root oneOf-anyOf-allOf beyond the dangling-$ref class this fixes. |
||
|
jkomyno
|
620075a5de | fix(openai): stop logging MCP server URLs to stdout | ||
|
jkomyno
|
8a56383b24 |
fix(core): cap automatic S3 download size at 100 MiB
`downloadFileFromS3` buffered the whole response with `arrayBuffer()`. The `s3Url` it fetches is a tool-execution response field — the same untrusted input the SSRF guard already defends against — so an oversized or endlessly streaming body could exhaust the host process's heap. Route the body through the existing `readResponseBodyWithLimit` guard, which pre-checks `Content-Length` and counts streamed bytes (the header can be absent or dishonest). The 100 MiB default matches the upload-from-URL sibling in the same module; `maxDownloadBytes` overrides it per call. Claude-Session: https://claude.ai/code/session_01K1hH9PMmd6KPKdkACX553z |
||
|
sdkrelease[bot]
|
dbe5a63965 | Release: update version | ||
|
Alberto Schiabel
|
08306f8bc1 | Merge branch 'next' into fix/error-subclass-names | ||
|
Alberto Schiabel
|
3c7b938bd1 | Merge branch 'next' into fix/telemetry-request-timeout | ||
|
Alberto Schiabel
|
81631f83f4 | Merge branch 'next' into fix/strict-mode-keep-optional-parameters | ||
|
jkomyno
|
9692db5c0a |
fix(openai-agents): honor the strict option
OpenAIAgentsProvider accepted { strict } but always registered tools with
strict: false and additionalProperties: true. Strict mode now registers
tools with strict: true and a schema normalized by toStrictJsonSchema
(optional parameters required-nullable), drops null arguments the tool
schema rejects before execution, and registers tools strict mode cannot
express without strict mode with a warning.
Co-authored-by: AseemPrasad <aseemprasad0520@gmail.com>
Claude-Session: https://claude.ai/code/session_01TDrxCHn2hg51HmxVstSUgs
|
||
|
jkomyno
|
3c3b4dae94 |
fix(mastra): keep optional parameters under strict mode
MastraProvider strict mode used the root-only, input-mutating removeNonRequiredProperties, so "strict" meant something different from the OpenAI providers. It now runs the same toStrictJsonSchema rewrite: optional parameters become required-nullable, tools strict mode cannot express keep their original schema with a warning, and null arguments the tool schema rejects are dropped before execution. Co-authored-by: AseemPrasad <aseemprasad0520@gmail.com> Claude-Session: https://claude.ai/code/session_01TDrxCHn2hg51HmxVstSUgs |
||
|
jkomyno
|
4f69975475 |
fix(core): keep optional parameters under strict mode instead of dropping them
toStrictJsonSchema now follows the contract OpenAI documents for structured outputs: every property becomes required and optional ones are widened to accept null, so the model keeps every parameter it could pass before. Type arrays stay as they are (the API accepts them and rejects type next to anyOf), so nullable objects stay nullable. Constructs strict mode cannot express (objects with arbitrary keys, allOf, prefixItems, unresolved $refs, non-object roots) are reported in `unsupported` instead of being narrowed. omitNullToolArguments drops a null argument only where the tool's own schema rejects it, so nullable fields keep an explicit null. The keyword taxonomy shared by the three schema walkers now lives in one place. Co-authored-by: AseemPrasad <aseemprasad0520@gmail.com> Claude-Session: https://claude.ai/code/session_01TDrxCHn2hg51HmxVstSUgs |
||
|
Alberto Schiabel
|
9e958948c5 |
fix(core): block sensitive upload paths hidden behind a symlinked directory (#4218)
# Description
Found by the scheduled security audit, while checking whether a test
failure on my other PR was pre-existing. It was — and the reason it
fails is a real gap in a shipped security control.
`isBlockedSensitiveFileUploadPath` (the GHSA-hp3h-89pf-5q58 denylist)
matched deny segments **only against the symlink-resolved path**. That
catches a benign name pointing at a secret — `~/innocent-name ->
~/nested/.aws/creds`, which the existing test covers — but misses the
inverse:
| Layout | Written path | Resolved path | Blocked before? |
|---|---|---|---|
| `~/innocent -> ~/.aws/creds` | no `.aws` | **`.aws`** | yes |
| `~/.claude -> /state/claude` | **`.claude`** | no `.claude` | **no** |
`~/.claude/settings.json` resolves to `/state/claude/settings.json`,
which has no `.claude` segment, so it sailed through — and `.claude` is
on the denylist precisely because it *"may contain API keys and project
context read by assistants"*.
This layout is not exotic. Dotfile managers (chezmoi, stow, yadm) and
containerised home directories produce it routinely — Composio's own
agent sandbox image has `/home/zen/.claude -> /state/claude`. For every
user in that shape the control was silently inactive, which is the worst
failure mode for a denylist: no error, no warning, upload proceeds.
The same hiding trick applies to the basename check (`~/.env ->
/state/plain-config`), so that path is fixed too.
## Why CI never caught this
`ts/packages/core/test/utils/sensitiveFileUploadPaths.test.ts` **already
asserts** the blocked behaviour:
```ts
expect(isBlockedSensitiveFileUploadPath(path.join(os.homedir(), '.claude', 'settings.json'))).toBe(true);
```
That assertion has been failing on `next` on any machine where
`~/.claude` is a symlink. It passes in CI only because `~/.claude` does
not exist on the runners: `existsSync` is false, no `realpath` runs, and
the written path keeps its `.claude` segment. The test is
environment-dependent, so green CI was never evidence the control
worked.
## The fix
The TypeScript `normalizePath` helper now returns both the written and
resolved segments, and the segment scan and basename check each consider
both. The Python guard now applies the same rule. Either path can carry
the denied name, so both SDKs inspect both forms.
# How did I test this PR
**The TypeScript fix is gated by tests — 3 fail without it, 13/13 pass
with it.**
Without the `src` change (test file only):
```
× blocks common credential directory segments
× blocks a sensitive directory that is itself a symlink to a plain path
× blocks a denied basename whose symlink target is named innocuously
Tests 3 failed | 10 passed (13)
```
With the fix:
```
Test Files 1 passed (1)
Tests 13 passed (13)
```
Note the first of those three is the **pre-existing** assertion quoted
above — this PR turns it green rather than adding it.
Three tests added, each building a real symlink in a temp dir:
- sensitive directory that is itself a symlink to a plain path (the
`~/.claude -> /state/claude` case), asserting both
`isBlockedSensitiveFileUploadPath` and that `assertSafeFileUploadPath`
throws
- denied basename whose symlink target is named innocuously (`.env ->
plain-config`)
- **negative case**: an ordinary file reached through a symlinked
directory (`docs/document.pdf`) is still allowed, so the fix does not
over-block
The Python parity change adds the same three cases. Before the Python
source change, the sensitive written directory and basename both
returned `False`; with the fix, all 11 focused Python tests pass.
**Full verification:**
| Command | Result |
|---|---|
| `vitest run` in `ts/packages/core` | **48 files, 1114 tests passed** |
| `pnpm typecheck` (workspace) | **14/14 tasks successful**, exit 0 |
| `oxlint` on both changed files | exit 0, clean |
| `prettier --check` on both changed files | "All matched files use
Prettier code style!" |
| `nox -s chk` in `python/` | Ruff and mypy passed |
| `nox -s tst` in `python/` | **1339 passed, 33 skipped**, exit 0 |
# Security
- No dependency changes, no new network calls, no new imports. The diff
is limited to the equivalent TypeScript and Python guards, their tests,
and the required `@composio/core` patch changeset.
- This **strengthens** an existing control and cannot weaken it: the
previous match set is a strict subset of the new one, so nothing that
was blocked before is allowed now. The added negative test pins that the
widening does not over-block ordinary files.
- **Grype** — `grype dir:ts/packages/core --only-fixed --fail-on medium`
→ reported below.
- **Socket** — could not run; `doppler secrets get SOCKET_API_TOKEN
--plain --project hermes --config dev_zen` returns empty in this cron
sandbox, so `socket ci` exits `Auth Error`. Reporting rather than
skipping silently.
- Unrelated pre-existing note: the repo's `pnpm audit --prod` comment
flags `extract-zip <=2.0.1` with `Patched versions >=2.0.2`, a version
that does not exist on npm. Details in #4217.
Origin: cron-48e51eab745f /
[zen-cron-44e260352d1a](https://zen.corp.composio.io/dashboard/#/chat/zen-cron-44e260352d1a)
Triggered by: saransh@composio.dev | Source: unknown
Session:
https://zen.corp.composio.io/dashboard/#/chat/zen-cron-44e260352d1a
|
||
|
jkomyno
|
449f4e128a | chore: add changeset for symlink path protection | ||
|
Alberto Schiabel
|
f174b28c3a |
fix(sdk): omit empty file-uploadable arguments from tool execution (#4238)
This PR: - closes https://github.com/ComposioHQ/composio/issues/4233 - stops forwarding `""` for a `file_uploadable` parameter (e.g. Gmail `attachment`) to the backend, which rejected it with `Input should be a valid dictionary or instance of FileUploadable` - Python: parameterizes the upload walker on a `leaf` handler and adds `FileHelper.drop_empty_file_uploads()`, run on both `Tools.execute` paths when `dangerously_allow_auto_upload_download_files` is off (the default) - TypeScript: moves the walker into the runtime-neutral `walkFileUploadableLeaves()` with a `DELETE_VALUE` sentinel and `dropEmptyFileUploads()`, so the flag-off path also works on edge runtimes; with the flag on, `''` is no longer attempted as an upload (previously threw `Either path or blob must be provided`) - TypeScript: `schemaHasFileProperty()` now looks through `$defs`/`definitions`, so the flag-off pass (and the existing one-shot warning) fire for `$ref`-based file schemas - keeps each SDK's existing `null` semantics: Python omits `None` as before, TypeScript still passes `null` through for schemas with a `null` variant - adds regression tests for both SDKs and a `@composio/core` changeset ## Context Reproduced against staging with `composio==0.16.0` and the current SDK: the live `GMAIL_CREATE_EMAIL_DRAFT` schema is `anyOf[FileUploadable, array[FileUploadable]]` with no `null` variant, and `""` yields the exact error from the issue on `no_auth` file tools (`TEXT_TO_PDF_UPLOAD_FILE`). With this change the backend sees the parameter as not provided, matching what the playground UI sends. |
||
|
jkomyno
|
fe66cbeb77 |
fix(sdk): omit empty file-uploadable arguments from tool execution
Both SDKs forwarded "" for a file_uploadable parameter (e.g. Gmail attachment) verbatim to the backend, which rejected it with a Pydantic validation error. Python only dropped it inside the opt-in auto-upload walker; TypeScript never did, and with auto-upload on it tried to upload the empty string. Run a schema-aware, upload-free pass on the default execute path that omits empty file values, and reuse the same walker for staging when auto-upload is enabled. Closes #4233 |
||
|
Alberto Schiabel
|
700327c2a6 | Merge branch 'next' into chore/changesets-v3-migration |