mirror of
https://github.com/ComposioHQ/composio.git
synced 2026-09-22 11:46:35 +08:00
google-example@0.1.3
5396 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 -connected-accounts-example@0.1.12 @composio/openai@0.12.3 typesafe-example@0.0.1 triggers-example@0.1.3 versioning-example@0.1.3 tools-example@0.1.3 toolkits-example@0.1.12 @e2e-tests/deno-tool-execution@0.0.1 @e2e-tests/cf-workers-tool-router-ai@0.0.3 @e2e-tests/node-custom-tools@0.0.3 @e2e-tests/node-json-schema-to-zod-v3@0.0.3 @e2e-tests/cf-workers-files@0.0.3 @e2e-tests/node-json-schema-to-zod-v4@0.0.3 @e2e-tests/node-mastra-tool-router-zod-v3@0.0.3 @e2e-tests/cf-workers-basic@0.0.3 mastra-example@0.1.3 @e2e-tests/node-mastra-tool-router-zod-v4@0.0.3 @e2e-tests/node-tool-router-files@0.0.3 @composio/vercel@0.12.1 @e2e-tests/node-tool-router-pagination@0.0.3 @composio/typesafe@0.1.1 @composio/cloudflare@0.10.3 tool-router-example@1.0.13 @composio/claude-agent-sdk@0.12.1 session-management-example@0.1.3 @composio/anthropic@0.11.2 anthropic-example@0.1.3 @composio/core@0.19.0 openai-example@0.1.12 modifiers-example@0.1.12 vercel-example@0.1.12 llamaindex-example@0.1.3 @composio/slim@0.19.0 @composio/google@0.11.1 @composio/experimental@0.2.5 langchain-example@0.1.12 @composio/json-schema-to-zod@0.3.3 json-schema-to-zod-example@0.1.3 google-example@0.1.3 @composio/langchain@0.11.1 file-handling-example@0.1.3 @composio/llamaindex@0.11.1 @composio/mastra@0.10.5 error-handling-example@0.1.12 @composio/openai-agents@0.11.1 @e2e-tests/node-claude-agent-sdk@0.0.3 mcp-example@0.1.3 cloudflare-wrangler-example@0.0.2 |
||
|
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 Twinepy@0.22.0 |
||
|
Saransh Rana
|
eb5f2b1938 |
fix(docs-agent): port Eve prompt and error handling hardening to next (#4549)
## What this is A port of #4389 from `main` to `next`. No new code. The six files are taken verbatim from `main`. #4389 merged into `main` on 2026-09-08. The docs site does not deploy from `main`, it deploys from `next`, so the fix never reached production. Verified on 2026-09-21: the repo's Production deployment is commit `4b5920bf7aa55c8a44657b060d4bd25ce7b13a9a`, which compares `identical` to `next`, and `docs/agent/lib/safety.ts` does not exist at that commit. Both findings were live in production. ## What it fixes Two AppSecure September findings against the docs assistant. **Finding 3, system prompt disclosure.** The assistant returned the upstream request payload on its error path, and that payload included the system message. An error was enough to leak the prompt. **Finding 2, scope guardrail bypass.** The scope guardrail was bypassed by wrapping an off-topic task inside a docs-looking request. The guardrail checked the shape of the request rather than the task inside it. Tracked as SEC-1064 and SEC-1061. ## Verification that this is a clean port `next` and `main` differed on these six files by exactly the #4389 patch and nothing else. Checked at blob level, not just line counts: | File | `next` vs pre-#4389 `main` (`711e609a`) | |---|---| | `docs/agent/agent.ts` | same blob `0781e59f` | | `docs/agent/instructions.md` | same blob `6fc4af3b` | | `docs/agent/channels/eve.ts` | same blob `c083c68b` | | `docs/agent/lib/safety.ts` | absent on both | | `docs/tests/static/eve-agent-fetch.test.ts` | absent on both | | `docs/tests/static/eve-safety.test.ts` | absent on both | For the three modified files the blob on `next` is identical to the blob on `main`'s pre-#4389 parent. For the three new files they are absent on both. So taking `main`'s version is exactly applying #4389, with no collateral revert of anything that landed on `next` afterwards. Confirmed a second way: `git diff next main` restricted to these six files is byte for byte the same as the #4389 patch, 13742 bytes, sha256 `6c934e56cb36614e...`. The staged diff of this branch's commit hashes to that same value. No drift had appeared since the earlier check. Nothing was rewritten or redesigned during the port. ## Tests Run locally in `docs/`, the commands behind `docs-tests.yml` and `docs-typescript-check.yml`: | Command | Result | |---|---| | `bun test tests/static/eve-safety.test.ts tests/static/eve-agent-fetch.test.ts tests/static/eve-agent-model-errors.test.ts` | 14 pass, 0 fail | | `bun run test` | 590 pass, 0 fail across 62 files | | `bun run lint` | exit 0, no findings in the changed files | | `bun run types:check` | exit 0 | Those three test files carry the regression coverage for both findings. The third is new in this branch; see below. --- ## Two review findings, addressed here Review bots raised two issues against code this PR ports. Both were pre-existing: the code is byte for byte what #4389 shipped to `main` on 2026-09-08, and both are live in production on `main` today. Neither was introduced by the port. Fixing them here gives up the property the PR originally sold, that its diff is provably exactly #4389. That is the right trade. The point of the PR is to close the two findings on the branch that deploys, and a fix that does not actually close the disclosure is worse than a messier diff. ### Codex, P1, `docs/agent/agent.ts`: right conclusion, wrong mechanism Codex said the system prompt still escapes because `@ai-sdk/provider-utils` catches custom-fetch rejections and rewraps them in an `APICallError` carrying `requestBodyValues`. That is not what the library does. In `handleFetchError` an error is only rewrapped if it is abort-like, a `TypeError` with message `fetch failed` / `failed to fetch` **and** a non-null `cause`, or carries a retryable network code somewhere in its cause chain. Everything else reaches `return error` and is rethrown untouched. Identical in the three copies installed here: `provider-utils` 5.0.36, `provider-utils-v6` 4.0.40, `provider-utils-v7` 5.0.11. `safeInceptionFetch` throws a plain `Error` with no cause and no code, so it passes through unwrapped. Driving `generateText` through the configured provider with a stubbed fetch confirmed it: no leak on non-2xx, on a 200 JSON error payload, or on a transport failure. But the conclusion was right. The prompt does still reach a client-visible error, by a route Codex did not name. `safeInceptionFetch` inspects a response body only when the content type is `application/json`. A streaming call returns `text/event-stream`, so the wrapper inspects nothing and returns the 200. The provider then reads an `{"error": ...}` frame out of the stream and builds the `APICallError` **itself**, at a call site that passes `requestBodyValues: body`. Nothing thrown from the fetch can preempt that, because on this path the fetch never throws. Reproduced against the pre-fix code: an `APICallError` whose `requestBodyValues.messages[0].content` was the system prompt verbatim. So the fix sanitizes at the model boundary rather than the fetch boundary, which is the one place that covers every route. `withSanitizedModelErrors` wraps the chat model so errors thrown by `doGenerate` and `doStream`, and error parts carried inside the stream, are replaced with the safe message. Abort and timeout errors still pass through untouched so the AI SDK can handle cancellation. `safeInceptionFetch` stays. It still injects the auth header and still stops the non-2xx `APICallError` from ever being built. It is the first line; the model wrapper is the backstop. ### Greptile, P2, `docs/agent/lib/safety.ts` `\bwhat\s+(are|were)\s+you\s+told\b` sat in `PROMPT_BYPASS_PATTERNS`, which returns `prompt-extraction` on its own without needing a private target. "What were you told about Composio sessions?" was steered to a refusal. Moved to `PROMPT_EXTRACTION_INTENT_PATTERNS`, so it has to pair with a private target the way the other intent patterns already do. "What were you told in your system prompt?" is still caught. The `ignore` / `disregard` / `override previous instructions` pattern stays unconditional, because it has no legitimate reading. ### Coverage for the two fixes `docs/tests/static/eve-agent-model-errors.test.ts` is new. It drives real `generateText` and `streamText` calls through the configured `inception` provider with a stubbed fetch, and asserts the system prompt appears nowhere in the thrown error once deep-serialized: `message`, `cause`, `requestBodyValues`, and a walk over every own property. A test that calls `safeInceptionFetch` directly cannot prove this, because the errors at issue are built after the fetch returns. Six cases: non-2xx, 200 with a JSON error payload, transport failure with a retryable cause, a streamed error frame before any output, a streamed error frame after output has started, and abort passthrough. With the model wrapper reverted, the two streaming cases fail and the other four pass, which is the split the source reading predicted. The four non-streaming cases pass without the wrapper because `safeInceptionFetch` already covers them, which is the same evidence that refutes the stated Codex mechanism. The two streaming failures are not the same kind, and the difference matters. The frame-before-any-output case fails on the leak assertion itself: the canary is present in `requestBodyValues`. That is the actual disclosure and the wrapper closes it. The frame-after-output-started case passes the leak assertion even without the wrapper, because that error part comes from `createProviderStreamError` and carries no request payload; it fails only on the message assertion. The stream transform there normalizes the error rather than closing a leak, and is kept as defence in depth. Two cases added to `eve-safety.test.ts` for the Greptile fix, one each way. The allow case fails against the old pattern list. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com> |
||
|
Deep Gori
|
a1873e90a7 |
fix(core): make HTTP status errors catchable as ComposioError (#4543)
## Summary In the Python SDK, HTTP failures from the generated client escape `except ComposioError`: `composio_client` has its own exception root, unrelated to `composio.exceptions.ComposioError`. An invalid API key, a 429 or a 500 therefore bypasses a handler written against the SDK's base error, while the TypeScript SDK covers the equivalent case (#4459). Opened this so there's something concrete to look at alongside the issue. Happy to rework it or close it if you'd prefer a different approach. Fixes #4537 ## Changes - `HttpClient` overrides `_make_status_error`, the single place the generated client builds status errors, and returns each error as a subclass of **both** the generated class and `ComposioError` (one cached subclass per generated class). - New `python/tests/test_client_errors.py` covering every mapped status plus an unmapped one, class reuse, and the SDK's existing `ToolNotFoundError` mapping. I went with this rather than wrapping errors at call sites, which is what I suggested on the issue, because it keeps every existing handler working: - `except ComposioError` now catches HTTP failures. - `except composio_client.AuthenticationError` / `APIStatusError` still work, with `status_code`, `response` and `body` unchanged. - The SDK's own mappings are untouched: `get_raw_composio_tool_by_slug` still raises `ToolNotFoundError` on 400/404 and re-raises other client errors unchanged, per its docstring and `test_tool_retrieval_errors.py`. The same holds for `TriggerTypeNotFound`. - No call sites change, so every endpoint is covered, including ones added later. On relying on a private method: `_make_status_error` is the hook the generated base client declares (`raise NotImplementedError()`) and calls for every status error, and `HttpClient` already overrides `_prepare_request` from the same base. `composio-client` is pinned exactly, and the new tests run through a real `HttpClient`, so a generator change that altered the hook would fail CI at the version bump rather than silently regress. Left alone: - **Transport-level errors.** `APIConnectionError` and `APITimeoutError` are raised by the base client without going through `_make_status_error`, so an HTTP timeout still escapes `except ComposioError`. (The issue said timeouts were already covered; that was true only for the SDK's own `ComposioSDKTimeoutError` from `wait_for_connection`, not for HTTP timeouts.) Happy to follow up if you want those covered too. - **The existing `composio.client.ComposioAPIError` alias** still points at the generated `APIError`, unchanged. The name I floated on the issue would have collided with it, and this approach doesn't need a new public class. ## Type of change - [x] Bug fix - [ ] New feature - [ ] Refactor/Chore - [ ] Documentation - [ ] Breaking change ## How Has This Been Tested? `python/tests/test_client_errors.py` runs a real `HttpClient` against an `httpx.MockTransport`. Each status (400, 401, 403, 404, 409, 422, 429, 500, and an unmapped 418) raises an error that is both a `ComposioError` and the expected generated class, with `status_code` preserved. Without the fix, 12 of the 13 new tests fail. From `python/`, Python 3.12, `composio-client==1.43.0`: ``` $ pytest tests/ -q 2072 passed, 1 skipped $ ruff check --config config/ruff.toml composio tests All checks passed! $ ruff format --config config/ruff.toml --check composio/client/__init__.py tests/test_client_errors.py 2 files already formatted $ mypy --config-file config/mypy.ini composio Success: no issues found in 58 source files ``` Live check against production with an invalid key: ```python from composio import Composio from composio.exceptions import ComposioError try: Composio(api_key="ak_invalid").create(user_id="u") except ComposioError as e: print(type(e), e.status_code) ``` On `next` this raises `composio_client.AuthenticationError`, which escapes the handler. On this branch the handler catches it, and it is still an `AuthenticationError` with status 401. ## 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 (no docs change; the public API is unchanged) - [x] I added tests or explain why not applicable - [ ] I added a changeset if this change affects published packages (Python-only change; CONTRIBUTING asks for changesets on published TypeScript packages) ## Additional context Found while integrating the Python SDK into [Inferra](https://github.com/deepgori/inferra), where a GitHub-issue filer caught `ComposioError` and missed the invalid-key path. --------- Co-authored-by: jkomyno <alberto@composio.dev> Co-authored-by: Alberto Schiabel <jkomyno@users.noreply.github.com> |
||
|
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. |
||
|
Brendan O'Leary
|
0154797ad8 |
docs: changelog for auth configs fetch limit raised to 200 (#4558)
## Summary - Adds a changelog entry for raising the auth configs fetch limit from 50 to 200, as requested by Palash Kala. ## Test plan - [ ] Verify the changelog `.mdx` file renders correctly on the docs site. |
||
|
Palash Kala [zen]
|
f372697eb3 |
docs: add changelog for auth configs fetch limit raised to 200
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> |
||
|
Alberto Schiabel
|
9b3d487d0b |
docs: note how MCP-backed toolkits get their behavior tags (#4553)
This PR:
- reopens https://github.com/ComposioHQ/composio/pull/4473 (D4) directly
against `next`; the original was merged into the D2 branch by mistake,
and https://github.com/ComposioHQ/composio/pull/4471 has been trimmed
back to D2 only
- cherry-picks the original D4 commit unchanged onto `next` (
|
||
|
Alberto Schiabel
|
96bfd2cc5e |
docs: proxy execute follows the session's toolkit lists (#4552)
This PR:
- reopens https://github.com/ComposioHQ/composio/pull/4472 (D3) directly
against `next`; the original was merged into the D2 branch by mistake,
and https://github.com/ComposioHQ/composio/pull/4471 has been trimmed
back to D2 only
- cherry-picks the original D3 commit unchanged onto `next` (
|
||
|
Alberto Schiabel
|
54f65c5637 |
docs: session proxy execute requires the Proxy execute permission (#4554)
This PR: - replaces https://github.com/ComposioHQ/composio/pull/4474 (D5), which was merged into the D2 branch by mistake and conflicted with the rewritten permissions reference on `next`; https://github.com/ComposioHQ/composio/pull/4471 has been trimmed back to D2 only - rewrites the change against the current "Session tool execution" / "Proxy execute (Legacy)" layout instead of the pre-rewrite page the original targeted - Session tool execution: drops the `/tool_router/session/{session_id}/proxy_execute` row and says proxy execution is not included; Proxy execute (Legacy): states it is the only permission that grants the session proxy route, from `session.proxyExecute()` or from the session's sandbox - Proxy execute page callout: requires Proxy execute; Session tool execution alone does not cover it - KB article `platform-project-api-key-permissions` (source under `docs/kb/articles`, generated guide regenerated with `bun run generate:kb`): same correction - merge after: ComposioHQ/platform#12846. Until it deploys, `next` is correct and this page must not go live. Kept as a draft for that reason PRD: https://app.notion.com/p/composio/Session-Governance-via-hints-Across-toolkits-3daf261a6dfe80df8e0ce337a2b26e08 Linear workstream: https://linear.app/composio/project/sessions-execution-governance-a0942233a0d0 Verification, run in `docs/` on this branch: `bun run types:check` passes, `bun run lint:links` reports 0 errors. `pnpm exec prettier --check` flags the touched mdx files on `next` already, so no reformatting was applied. |
||
|
sdkrelease[bot]
|
5840b2d62f |
docs: update toolkits, API spec, and meta tools data (#4540)
## Summary Automated sync of backend data into the docs site. - Trigger: `schedule` - Dispatch action: `n/a` - Source commit: `n/a` ## What changed - **Toolkit catalog** (`docs/public/data/toolkits.json`, `toolkits-list.json`) — refreshed list of available toolkits, auth schemes, and tools from the backend API - **OpenAPI specs** (`docs/public/openapi.json`, `docs/public/openapi-v3.json`, `docs/public/openapi-webhooks.json`) — latest v3.1 and v3.0 API specifications plus the webhook-events spec, fetched from production - **API reference pages** (`docs/content/reference/api-reference/`, `docs/content/reference/v3/api-reference/`) — regenerated index pages for both API versions - **Meta tools reference** (`docs/public/data/meta-tools.json`, `docs/content/toolkits/meta-tools/*.mdx`) — updated meta tool schemas and reference docs Co-authored-by: Sushmithamallesh <19796925+Sushmithamallesh@users.noreply.github.com> Co-authored-by: Alberto Schiabel <jkomyno@users.noreply.github.com> |
||
|
sdkrelease[bot]
|
64f7efe69d |
docs: update TypeScript SDK reference from source (#4534)
## 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> |
||
|
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)@composio/cli@0.4.2-beta.400 |
||
|
palash-c
|
af4cae6e7c |
docs: list POST /toolkits/multi as a read route for scoped API keys (#4539)
## Summary Updates the Scoped Project API Key reference page to match the backend fix in ComposioHQ/platform#13062 ([PLEN-3940](https://linear.app/composio/issue/PLEN-3940/scoped-api-keys-post-toolkitsmulti-is-cataloged-as-write-so-read-only)). `POST /toolkits/multi` only fetches toolkits, but it was cataloged as the single write route of the Toolkits permission area, so a read-only key got a 403 on it. The backend now treats it as a read, which leaves Toolkits with no write routes. - `/toolkits/multi` row: Write -> Read - Toolkits available levels: "No access, Read only" (was all four levels) - Toolkits description: "View toolkits." (was "View and install toolkits.") ## Merge order Merge after ComposioHQ/platform#13062 is deployed, so the page does not describe behavior that is not live yet. Not in this PR: a changelog entry. It needs the backend deploy date. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com> |
||
|
sdkrelease[bot]
|
bd5984e133 |
chore(cli): refresh baked toolkit slugs (#4548)
## Summary Automated refresh of the toolkit slugs the CLI knows without asking the API, generated by `ts/packages/cli/scripts/generate-toolkit-slugs.ts`. Toolkits added since the last refresh currently cost users one toolkit-list fetch (~2 s) the first time they run one of that toolkit's tools. Merging this makes them free. The generator refuses to write a list that is short, malformed, or missing staple toolkits, so a bad fetch opens no PR at all. Co-authored-by: jkomyno <12381818+jkomyno@users.noreply.github.com>@composio/cli@0.4.2-beta.399 |
||
|
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. |
||
|
sdkrelease[bot]
|
00d252dd49 |
docs: update Python SDK reference from source (#4500)
## 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> |
||
|
sdkrelease[bot]
|
d2ea930ce9 |
docs: update toolkits, API spec, and meta tools data (#4531)
## Summary Automated sync of backend data into the docs site. - Trigger: `schedule` - Dispatch action: `n/a` - Source commit: `n/a` ## What changed - **Toolkit catalog** (`docs/public/data/toolkits.json`, `toolkits-list.json`) — refreshed list of available toolkits, auth schemes, and tools from the backend API - **OpenAPI specs** (`docs/public/openapi.json`, `docs/public/openapi-v3.json`, `docs/public/openapi-webhooks.json`) — latest v3.1 and v3.0 API specifications plus the webhook-events spec, fetched from production - **API reference pages** (`docs/content/reference/api-reference/`, `docs/content/reference/v3/api-reference/`) — regenerated index pages for both API versions - **Meta tools reference** (`docs/public/data/meta-tools.json`, `docs/content/toolkits/meta-tools/*.mdx`) — updated meta tool schemas and reference docs Co-authored-by: Sushmithamallesh <19796925+Sushmithamallesh@users.noreply.github.com> |
||
|
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). |
||
|
Brendan O'Leary
|
b27c24d00d |
docs: update toolkits, API spec, and meta tools data (#4519)
## Summary Automated sync of backend data into the docs site. - Trigger: `schedule` - Dispatch action: `n/a` - Source commit: `n/a` ## What changed - **Toolkit catalog** (`docs/public/data/toolkits.json`, `toolkits-list.json`) — refreshed list of available toolkits, auth schemes, and tools from the backend API - **OpenAPI specs** (`docs/public/openapi.json`, `docs/public/openapi-v3.json`, `docs/public/openapi-webhooks.json`) — latest v3.1 and v3.0 API specifications plus the webhook-events spec, fetched from production - **API reference pages** (`docs/content/reference/api-reference/`, `docs/content/reference/v3/api-reference/`) — regenerated index pages for both API versions - **Meta tools reference** (`docs/public/data/meta-tools.json`, `docs/content/toolkits/meta-tools/*.mdx`) — updated meta tool schemas and reference docs |
||
|
Brendan O'Leary
|
756ea915f7 |
docs: update TypeScript SDK reference from source (#4486)
## 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). |
||
|
Sushmithamallesh
|
e452ef4897 | docs: update toolkits and API data | ||
|
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] ``` |
||
|
shams haroon
|
bfc654ac66 | fix(typesafe): preserve prototype-named caller arguments | ||
|
shams haroon
|
cf15b62e60 | fix(typesafe): guard required arguments in compilation and execution | ||
|
Brendan O'Leary
|
6f0cff06fe |
docs: order API endpoints by lifecycle (#4517)
## Summary - Order generated API navigation as GET, POST, PATCH or PUT, then DELETE. - Preserve authored sidebar items and existing order within each method. - Add regression coverage for the Auth Configs endpoint list. ## Testing - `bun test tests/static/api-reference-routes.test.ts` - `bun ./node_modules/typescript-7/bin/tsc --noEmit` - `bun test tests/static/` (575 passed; one localhost test cannot bind inside the sandbox) - `bun test tests/static/kb-query-analytics.test.ts` outside the sandbox (14 passed) Fixes DEVREL-135 |
||
|
sdkrelease[bot]
|
25fe8425a9 |
docs(kb): refresh public support knowledge (#4516)
Automated knowledge-base refresh for `ComposioHQ/support-knowledge`. - Source commit: `5eac683455ff252a7a3b62f33ab6566445009b52` (unchanged; rebuilt a stale semantic artifact) - Regenerated public KB pages and search records - Reused unchanged vectors and rebuilt the checked semantic artifact - Ran KB freshness and semantic-artifact verification Co-authored-by: sohambasu963 <80603154+sohambasu963@users.noreply.github.com> |
||
|
Brendan O'Leary
|
d9a14c3abd | docs: put read endpoints first | ||
|
Brendan O'Leary
|
00f2f45e13 | docs: order API endpoints by lifecycle | ||
|
jkomyno
|
cc1248370b |
fix(typesafe): block null-leaf container swaps and tighten gate option checks
- Treat dict/list as their own leaf kind when asserting a redactor masks
only, so a redactor cannot replace a JSON null leaf with an object or
array while the gate would approve the altered call (Python now matches
the TS scalarTypeOf behavior).
- Reject non-number gate thresholds ('', '0.9', true) at construction on
the TS side, matching the strict Python check.
- Omit the gate state context key when getContext returns null, matching
Python and decide's context handling.
- Pin all three with regression tests on both SDKs, and assert the
context key is absent from the sent state when no getContext is given.
|
||
|
jkomyno
|
8878a9bcc5 |
fix(typesafe): fail closed on redaction structure changes and invalid gate options
Review findings from the TypeSafe (Jev) provider PR, fixed in both SDKs: - The confidence gate enforces a masking-only redaction contract: the redacted arguments must keep the original JSON structure (same keys, same array lengths) with every leaf replaced by a value of the same scalar type, or the call is blocked. Jev can no longer approve a call that differs from the one that runs. - `onUnavailable` is validated when the gate is built, in the companion both entry points share: a typo'd mode raises TypesafeInvalidOptionsError at construction instead of failing open at check time. - `minItems` is carried through classification and compilation into array arguments, and a selection with fewer members than `minItems` counts as not stated, so a required array stays missing instead of executing with `[]`. - The boolean class gains `nullable`: a ['boolean', 'null'] property compiles to a yes/no/null Choice so Jev can bind null; plain booleans still compile to yes/no only, and one-boolean enum sets stay open-ended. - `stable()` rejects `undefined` wherever it appears instead of rewriting it, and the gate builds its state without a `context` key when there is no context, so a context-less gate call still works. - `Probability` and the classify number type accept JSON integers, so an API score of 0 or 1 and integer `maxItems`/`minItems` parse instead of marking the property open-ended or the response malformed. Bools, strings, NaN, inf, and out-of-range values are still rejected. |
||
|
Brendan O'Leary
|
a648ceff3f | fix(docs): preserve generated parameter metadata | ||
|
jkomyno
|
1501ae6fdb | test: classify the TypeSafe provider in the $ref handling contract | ||
|
Brendan O'Leary
|
705888faff |
docs: describe the four verdict hints sessions filter on (#4470)
## Why Requirement 1 of the PRD: sessions accept all four verdict hints. The Configuring Sessions tag table listed the four MCP-spec hints, two of which (idempotentHint, openWorldHint) are set on a minority of tools. Every tool carries at least one of readOnlyHint, createHint, updateHint, destructiveHint. ## What - Tag table leads with the four verdict hints and says every tool carries at least one; idempotentHint and openWorldHint noted as accepted with partial coverage. - Callout: the v3 tools endpoints default to the pinned version 00000000_00, sessions read latest. - Python example uses createHint. The TypeScript twoslash example stays on readOnlyHint so docs CI passes against the published SDK; switch it to createHint when merging, after #4467 is released. - Python and TypeScript SDK reference docs list the widened enum. ## Merge after API: platform#12843 (accept createHint and updateHint). SDK: composio#4467 released. PRD: https://app.notion.com/p/composio/Session-Governance-via-hints-Across-toolkits-3daf261a6dfe80df8e0ce337a2b26e08 Linear workstream: https://linear.app/composio/project/sessions-execution-governance-a0942233a0d0 Stack order (merge top to bottom, each after its API change is deployed): D1 verdict hints, D2 precedence, D3 proxy execute toolkit lists, D4 MCP classification, D5 proxy execute API key permission. Verification, run in `docs/` at the top of the stack (D5 head, which contains this PR): `bun run types:check` passes, `bun run build` compiles (twoslash blocks type-check against the published `@composio/core`), `bun run lint:links` reports 0 errors, `bun run test` 568 pass. `pnpm exec prettier --check` flags the changed mdx files on `next` already, so no reformatting was applied. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01VHkYsmhteM1jJQoaoruiP3 |
||
|
Brendan O'Leary
|
1c135f93db |
docs(kb): refresh public support knowledge (#4455)
Automated knowledge-base refresh for `ComposioHQ/support-knowledge`. - Source commit: `5eac683455ff252a7a3b62f33ab6566445009b52` (unchanged; rebuilt a stale semantic artifact) - Regenerated public KB pages and search records - Reused unchanged vectors and rebuilt the checked semantic artifact - Ran KB freshness and semantic-artifact verification |
||
|
Brendan O'Leary
|
f34260ce54 |
docs: update toolkits, API spec, and meta tools data (#4514)
## Summary Automated sync of backend data into the docs site. - Trigger: `schedule` - Dispatch action: `n/a` - Source commit: `n/a` ## What changed - **Toolkit catalog** (`docs/public/data/toolkits.json`, `toolkits-list.json`) — refreshed list of available toolkits, auth schemes, and tools from the backend API - **OpenAPI specs** (`docs/public/openapi.json`, `docs/public/openapi-v3.json`, `docs/public/openapi-webhooks.json`) — latest v3.1 and v3.0 API specifications plus the webhook-events spec, fetched from production - **API reference pages** (`docs/content/reference/api-reference/`, `docs/content/reference/v3/api-reference/`) — regenerated index pages for both API versions - **Meta tools reference** (`docs/public/data/meta-tools.json`, `docs/content/toolkits/meta-tools/*.mdx`) — updated meta tool schemas and reference docs |
||
|
Brendan O'Leary
|
85af5a17b1 |
docs: remove Strava toolkit FAQ and KB content (#4515)
## Summary - Strava is no longer present in the toolkit catalog (`docs/public/data/toolkits.json` / `toolkits-list.json` have no `strava` entry), leaving its docs orphaned. - Removes the Strava toolkit FAQ page (`docs/content/toolkits/faq/strava.md`). - Removes the Strava KB guide and its source: `docs/kb/source/toolkits/strava/public.md`, `docs/kb/articles/toolkits-strava.md`, the generated `docs/content/kb/guide/toolkits-strava.mdx`, and the corresponding entries in `docs/kb/manifest.json` and `docs/content/kb/guide/meta.json`. - Removes the Strava OAuth guide entry from `docs/kb/external-sources/auth-guides.json`. - Left `docs/content/changelog/*.mdx` untouched (historical release records). ## Note - `docs/kb/semantic-index.json` is a generated embeddings artifact and will now be stale relative to `kb/manifest.json`. It needs `bun run build:kb-semantic` (requires `OPENAI_API_KEY`) or the "Docs - Rebuild KB Semantic Artifact" CI workflow to regenerate — I didn't have the credentials/toolchain in this sandbox to run it, so it's left as-is for a maintainer/CI to refresh. ## Test plan - [x] Validated edited JSON files parse correctly (`manifest.json`, `auth-guides.json`, `meta.json`) - [x] Confirmed no other registry (toolkits.json, toolkits-list.json, page routing) references the `strava` slug - [ ] CI: `check:kb` / `check:kb-semantic` (semantic index rebuild needed, see note above) 🤖 Generated with [Claude Code](https://claude.com/claude-code) |
||
|
jkomyno
|
b2cf623045 |
refactor(py): mirror the TypeSafe provider simplification
Drop tool_thresholds, describe, and log_level, collapse the API error subclasses, validate decisions against the public TypedDicts, and read the question corpus from the TypeScript package instead of a second copy. |
||
|
jkomyno
|
ab0a5fa88c |
refactor(typesafe): drop per-tool thresholds, describe overrides, and logLevel
Collapse the TypesafeApiError subclasses into one error with a reason field, consolidate the question corpus to nine tools, and cut the tests that exercised the TypeSafe SDK instead of the provider. |
||
|
composio-zen[bot]
|
ca2e4df0ed |
docs: remove Strava toolkit FAQ and KB content
Strava is no longer in the toolkit catalog (public/data/toolkits*.json has no strava entry), so drop its orphaned FAQ page, KB guide, and KB source/manifest/registry entries. kb/semantic-index.json will go stale from the manifest change; it regenerates via the existing "Docs - Rebuild KB Semantic Artifact" workflow (or `bun run build:kb-semantic`). |
||
|
Sushmithamallesh
|
d267eee4ec | docs: update toolkits and API data | ||
|
jkomyno
|
7681b90ad9 | docs: list the TypeSafe provider | ||
|
jkomyno
|
23ee594a5e | ci: run the TypeSafe provider tests and watch the shared question corpus | ||
|
jkomyno
|
36a7ed4405 | feat(py): add composio-typesafe provider for TypeSafe Jev | ||
|
jkomyno
|
d36048fbe7 | feat(typesafe): add TypeSafe Jev provider for TypeScript | ||
|
jkomyno
|
796a541343 | docs: auto-generate TypeScript SDK reference | ||
|
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@composio/cli@0.4.2-beta.398 |
||
|
sohambasu963
|
29954ae91d | docs(kb): refresh public support knowledge | ||
|
Anshu Garg
|
3c5a645023 |
docs: update toolkits, API spec, and meta tools data (#4510)
## Summary Automated sync of backend data into the docs site. - Trigger: `schedule` - Dispatch action: `n/a` - Source commit: `n/a` ## What changed - **Toolkit catalog** (`docs/public/data/toolkits.json`, `toolkits-list.json`) — refreshed list of available toolkits, auth schemes, and tools from the backend API - **OpenAPI specs** (`docs/public/openapi.json`, `docs/public/openapi-v3.json`, `docs/public/openapi-webhooks.json`) — latest v3.1 and v3.0 API specifications plus the webhook-events spec, fetched from production - **API reference pages** (`docs/content/reference/api-reference/`, `docs/content/reference/v3/api-reference/`) — regenerated index pages for both API versions - **Meta tools reference** (`docs/public/data/meta-tools.json`, `docs/content/toolkits/meta-tools/*.mdx`) — updated meta tool schemas and reference docs |
||
|
Anshu Garg
|
91076fbd8a |
docs(auth): note the auto-populated connection display_name (#4503)
## Why Support and customers (e.g. athena) keep asking how to tell apart multiple connected accounts under one auth config. Platform [#12507](https://github.com/ComposioHQ/platform/pull/12507) + [#12519](https://github.com/ComposioHQ/platform/pull/12519) shipped an auto-populated provider identity for this, but the docs never mention it. Closes the docs follow-up on [PLEN-3541](https://linear.app/composio/issue/PLEN-3541). ## What One line in the **Aliases** section of *Managing multiple connected accounts*: to identify an account by its provider-side identity (Gmail address, GitHub username), read the read-only `display_name` Composio auto-populates at `state.val.displayName` once the connection is active — distinct from the user-set `alias`. ## Impact Docs-only. No code, no API change. ## Rollout The feature is currently in staging; merge/publish once PLEN-3541 is live in prod. 🤖 Generated with [Claude Code](https://claude.com/claude-code) |