This PR:
- activates the descriptor-seam rule group:
`commands/command-introspection.ts` becomes the only module allowed to
import `CommandDescriptor`/`Usage` from `@effect/cli` — the redesign
seam the Effect CLI v4 migration will reimplement
- routes root command assembly, preflight parsing, help routing, and
value-option collection through the seam helpers instead of descriptor
walks
- replaces the Zod-backed tool-input adapter with an internal
`@composio/json-schema-to-effect-schema` compiler backed by the
eval-free `@cfworker/json-schema` interpreter
- normalizes the OpenAPI and Composio extensions accepted by the
previous validator, while preserving typed `ToolInputValidationError`
failures, field paths, multi-error reporting, and typo suggestions
- extends the descriptor and Zod boundaries to reject static imports,
dynamic `import()`, and `require()` bypasses
- adds compiler parity tests plus CLI regression coverage for multiple
simultaneous field and unknown-key failures
- introspection tests pin that the helpers yield identical descriptors
and usage strings
---
**Stack** (re-slice of https://github.com/ComposioHQ/composio/pull/3859;
each PR targets its parent and auto-retargets to `next` as parents
merge):
1. https://github.com/ComposioHQ/composio/pull/3877 — guidelines + inert
rule groups
2. https://github.com/ComposioHQ/composio/pull/3878 — `new Function()`
eval security fix
3. https://github.com/ComposioHQ/composio/pull/3879 — behavioral fix
pack
4. https://github.com/ComposioHQ/composio/pull/3880 — platform-imports
rule + migration
5. https://github.com/ComposioHQ/composio/pull/3881 — terminal-streams
rule + TerminalUI boundary
6. https://github.com/ComposioHQ/composio/pull/3882 — descriptor seam +
Zod→Schema ← **this PR**
7. https://github.com/ComposioHQ/composio/pull/3883 — test-tree lint +
deterministic suites
8. https://github.com/ComposioHQ/composio/pull/3884 — typed error
boundaries + v4 seams
9. https://github.com/ComposioHQ/composio/pull/3885 — try/catch+env ban
+ boundary ratchet
On stacked bases CI runs lint/build and the CLI Docker e2e job; unit
tests and typecheck are verified locally per PR and re-verified by full
CI when each PR is retargeted to `next`.
This PR:
- activates the terminal-streams rule group:
`process.stdout`/`process.stderr` are now ESLint-banned in CLI source,
with `services/terminal-ui.ts` as the sole stream boundary (that file is
itself held to the try/catch + `process.env` restrictions early)
- extends `TerminalUI` with `capabilities` (TTY/interactivity/decoration
detection) and a raw `error()` writer, replacing `utils/stdio.ts`
(deleted)
- makes analytics dispatch Effect-native and delivers detached telemetry
through `DetachedProcess`, staying non-fatal on failure
- consolidates runtime debug logging into a `RuntimeDebugLogger` service
and rebuilds `cli-main` around `showUpdateNotice`/telemetry as Effects
with errors reported via `ui.error`
- the update checker reads terminal capabilities from the service and
keeps its fire-and-forget contract
---
**Stack** (re-slice of https://github.com/ComposioHQ/composio/pull/3859;
each PR targets its parent and auto-retargets to `next` as parents
merge):
1. https://github.com/ComposioHQ/composio/pull/3877 — guidelines + inert
rule groups
2. https://github.com/ComposioHQ/composio/pull/3878 — `new Function()`
eval security fix
3. https://github.com/ComposioHQ/composio/pull/3879 — behavioral fix
pack
4. https://github.com/ComposioHQ/composio/pull/3880 — platform-imports
rule + migration
5. https://github.com/ComposioHQ/composio/pull/3881 — terminal-streams
rule + TerminalUI boundary ← **this PR**
6. https://github.com/ComposioHQ/composio/pull/3882 — descriptor seam +
zod→Schema
7. https://github.com/ComposioHQ/composio/pull/3883 — test-tree lint +
deterministic suites
8. https://github.com/ComposioHQ/composio/pull/3884 — typed error
boundaries + v4 seams
9. https://github.com/ComposioHQ/composio/pull/3885 — try/catch+env ban
+ boundary ratchet
On stacked bases CI runs lint/build and the CLI Docker e2e job; unit
tests and typecheck are verified locally per PR and re-verified by full
CI when each PR is retargeted to `next`.
This PR:
- activates the platform-imports rule group: `node:fs`, `node:path`,
`node:os`, and `child_process` are now ESLint-banned in CLI source
- migrates ~36 files to `FileSystem`/`Path`/`Command` from
`@effect/platform`, introducing the `NodeOs` and `DetachedProcess`
service boundaries and Effect-native run-companion module resolution
- keeps the sanctioned permanent boundaries (`node-os.ts`,
`detached-process.ts`, `run-subagent-output-mcp.ts`,
`cli-user-config.ts`, the child-process companion runtime) on inline `--
reason` disables
- files whose compliant rewrite belongs to a later slice carry temporary
inline disables naming the owning PR; a small sync bridge in
`run-companion-modules.ts` keeps the not-yet-migrated Promise-based
callers working until the typed-error slice removes it
- adds A-theme coverage: `NodeOs` platform info through Effect, session
artifacts via `FileSystem` with symlink and HOME-less handling,
skill-root discovery, and safe-output-path traversal guards
---
**Stack** (re-slice of https://github.com/ComposioHQ/composio/pull/3859;
each PR targets its parent and auto-retargets to `next` as parents
merge):
1. https://github.com/ComposioHQ/composio/pull/3877 — guidelines + inert
rule groups
2. https://github.com/ComposioHQ/composio/pull/3878 — `new Function()`
eval security fix
3. https://github.com/ComposioHQ/composio/pull/3879 — behavioral fix
pack
4. https://github.com/ComposioHQ/composio/pull/3880 — platform-imports
rule + migration ← **this PR**
5. https://github.com/ComposioHQ/composio/pull/3881 — terminal-streams
rule + TerminalUI boundary
6. https://github.com/ComposioHQ/composio/pull/3882 — descriptor seam +
zod→Schema
7. https://github.com/ComposioHQ/composio/pull/3883 — test-tree lint +
deterministic suites
8. https://github.com/ComposioHQ/composio/pull/3884 — typed error
boundaries + v4 seams
9. https://github.com/ComposioHQ/composio/pull/3885 — try/catch+env ban
+ boundary ratchet
On stacked bases CI runs lint/build and the CLI Docker e2e job; unit
tests and typecheck are verified locally per PR and re-verified by full
CI when each PR is retargeted to `next`.
## Review follow-up
- `DetachedProcess` now waits for Node’s `spawn` or `error` event, so
ENOENT/EACCES become typed failures instead of false success; focused
tests cover failure and success.
- the platform-import rule now rejects bare `fs`, `fs/*`, `os`, and
`path` specifiers as well as their `node:` forms; the two exposed path
imports now use Effect `Path`.
- run-companion self-repair again honors unprefixed `GITHUB_*` values
first, with `COMPOSIO_GITHUB_*` fallback and regression coverage for
both contracts.
Verification: CLI tests (95 files, 834 passed, 1 skipped), workspace
TypeScript typecheck, scoped ESLint (0 errors), CLI build, Prettier, and
`git diff --check`.
This PR:
- lands ten behavioral fixes as one commit each, so `git show` reviews
standalone
- fails the tool-permission gate closed: an unknown snapshot state or a
failed policy resolve on a controls-enabled org now synthesizes an
`ask_every_call` snapshot (never persisted) instead of silently skipping
the gate, and interactive approval UI never spawns where nobody can
answer it (CI/Vitest)
- surfaces realtime subscription failures as typed errors: `composio
listen` prints one actionable line mentioning `composio login`, cleans
up temporary triggers, and exits 1 instead of dumping a captured defect
- tolerates newer connected-account payloads with a fallback decode
whose field allowlist keeps credential-bearing fields (`state`, `data`)
out of `link --list` output
- decodes persisted caches and GitHub release listings per entry, so one
corrupt or version-skewed entry drops only itself
- extracts API error details field by field, renders the deepest cause
in pretty errors, and accepts `null` optional strings in agent API
responses
---
**Stack** (re-slice of https://github.com/ComposioHQ/composio/pull/3859;
each PR targets its parent and auto-retargets to `next` as parents
merge):
1. https://github.com/ComposioHQ/composio/pull/3877 — guidelines + inert
rule groups
2. https://github.com/ComposioHQ/composio/pull/3878 — `new Function()`
eval security fix
3. https://github.com/ComposioHQ/composio/pull/3879 — behavioral fix
pack ← **this PR**
4. https://github.com/ComposioHQ/composio/pull/3880 — platform-imports
rule + migration
5. https://github.com/ComposioHQ/composio/pull/3881 — terminal-streams
rule + TerminalUI boundary
6. https://github.com/ComposioHQ/composio/pull/3882 — descriptor seam +
zod→Schema
7. https://github.com/ComposioHQ/composio/pull/3883 — test-tree lint +
deterministic suites
8. https://github.com/ComposioHQ/composio/pull/3884 — typed error
boundaries + v4 seams
9. https://github.com/ComposioHQ/composio/pull/3885 — try/catch+env ban
+ boundary ratchet
On stacked bases CI runs lint/build and the CLI Docker e2e job; unit
tests and typecheck are verified locally per PR and re-verified by full
CI when each PR is retargeted to `next`.
This PR:
- removes an in-process arbitrary-code-execution surface:
`parse-json-ish.ts` fell back to `Function("return (…)")()` for any
`tools execute --data`, `listen --params`, or `proxy` body value that
failed JSON and comment-JSON parsing — the CLI is agent-facing and
`--data` also accepts `@file` and stdin, so crafted or prompt-injected
input reached the eval
- lands the parser in its final consolidated shape:
`src/utils/parse-json.ts` parses JSON5 (unquoted keys, single quotes,
trailing commas, comments) without evaluating anything and returns
`Either` with a typed `JsonParsingError`
- consolidates the `effect-errors` read-json duplicates onto the same
parser and swaps `comment-json` for `json5` (the stack's only lockfile
change)
- pins code-execution probes in unit tests (`new Date()`, computed
expressions, `globalThis` writes are rejected, never evaluated)
- intentional narrowing: JS expressions such as `1+1` that only worked
because of the eval now fail with a parse error; proxy bodies that are
not JSON5 records fall back to the raw string
---
**Stack** (re-slice of https://github.com/ComposioHQ/composio/pull/3859;
each PR targets its parent and auto-retargets to `next` as parents
merge):
1. https://github.com/ComposioHQ/composio/pull/3877 — guidelines + inert
rule groups
2. https://github.com/ComposioHQ/composio/pull/3878 — `new Function()`
eval security fix ← **this PR**
3. https://github.com/ComposioHQ/composio/pull/3879 — behavioral fix
pack
4. https://github.com/ComposioHQ/composio/pull/3880 — platform-imports
rule + migration
5. https://github.com/ComposioHQ/composio/pull/3881 — terminal-streams
rule + TerminalUI boundary
6. https://github.com/ComposioHQ/composio/pull/3882 — descriptor seam +
zod→Schema
7. https://github.com/ComposioHQ/composio/pull/3883 — test-tree lint +
deterministic suites
8. https://github.com/ComposioHQ/composio/pull/3884 — typed error
boundaries + v4 seams
9. https://github.com/ComposioHQ/composio/pull/3885 — try/catch+env ban
+ boundary ratchet
On stacked bases CI runs lint/build and the CLI Docker e2e job; unit
tests and typecheck are verified locally per PR and re-verified by full
CI when each PR is retargeted to `next`.
# Description
Removes the DiscordBot FAQ entry
`docs/content/toolkits/faq/discordbot.md`, which documented a "401 on
the default app" caused by the Composio-managed/shared DiscordBot bot
token being rejected by Discord.
That managed default-app bot-token issue has since been **resolved**, so
the FAQ is now stale. Leaving it up is actively misleading — it tells
users the default app is broken and pushes them to create their own
custom DiscordBot credentials, which is unnecessary now and has itself
been a source of support confusion (e.g. Plain T-14278, where a customer
went down the custom-credentials path).
Scope: single content file. FAQ entries are loaded per-toolkit-slug at
`content/toolkits/faq/${slug}.md`; `readToolkitFaq()` already
try/catches a missing file and returns `null`, and `FaqSection`/the
`llms.mdx` route both no-op when the FAQ is empty. There is no
manifest/index listing `discordbot`, so removal is clean with no
dangling references.
# How did I test this PR
- `grep -rni "401 on the default app|DiscordBot return 401|managed
bot-token" docs` after deletion → **no remaining references** anywhere
in the docs (content, components, prebuilt `toolkits.json`, search
index).
- Verified the loader tolerates the missing file:
`docs/app/(home)/toolkits/[[...slug]]/page.tsx:111` `readToolkitFaq()`
catches the read error → returns `null`; `FaqSection` renders nothing on
empty; `docs/app/llms.mdx/[[...slug]]/route.ts:671` gates on
`faqMarkdown && faqMarkdown.trim()`. So the DiscordBot toolkit page +
llms.mdx simply render without a FAQ section — no build break.
- Confirmed FAQ discovery is purely file-existence based (no hardcoded
slug list), so no index needed updating.
Co-authored-by: Zen Agent <zen@composio.dev>
Co-authored-by: abhishek <abhishek@composio.dev>
This PR:
- removes the stale `@composio/cli` changeset that wedges
`changesets/action` and preserves its release note in the CLI changelog
- adds `validate:changesets` before the TypeScript release action and
covers ignored-package changesets in the release regression suite
- makes the guard read changeset files directly so it also works in
shallow and detached CI checkouts
- refreshes `mise.lock` after the pinned Python standalone artifacts
moved to the 20260718 build
- adds the repo-local `cli-release` skill with beta, stable-promotion,
verification, and failure-recovery procedures
- replaces the contradictory "stable via changeset" contributor guidance
with the tested-beta promotion path
- extends skill taxonomy, routing probes, and PR path filters so the
guard cannot silently drift
## Regression coverage
The validator test creates a changeset fixture outside a Git repository,
verifies that an ignored CLI package is rejected, then verifies that a
normal package changeset passes. This reproduces the shallow-checkout
failure without relying on a local `next` ref.
## Verification
- `pnpm validate:agent-skills`
- `pnpm validate:skill-routing`
- `pnpm validate:changesets`
- `pnpm test:release-workflow`
- `pnpm lint`
- `pnpm install --frozen-lockfile`
- all 24 TypeScript package test tasks
- skill-creator `quick_validate.py`
- Prettier check
- `git diff --check`
- manual beta release
[`@composio/cli@0.2.33-beta.294`](https://github.com/ComposioHQ/composio/releases/tag/%40composio/cli%400.2.33-beta.294):
33/33 release and installation jobs passed
## What
Rewrites `/docs/claude-code-plugin` to match the shipped plugin. The
plugin was redesigned from an MCP-server bundle to a CLI-based plugin,
but the page still documented the old design — and the new page is
written benefit-first: what you can do with it and how to get it, not
how it's built.
## Why
The old page was wrong on essentially everything a reader would act on:
- **Install command didn't exist**: it said `/plugin install
composio-mcp@composio`; the plugin is `composio@composio`.
- **Bundled skills don't exist**: `composio-mcp`, `onboarding`,
`company-activity-summary`, and `prefer-composio` were removed with the
redesign.
- **No bundled MCP server**: the page (and its troubleshooting section)
claimed the plugin ships the Composio Connect MCP server; it doesn't.
- **Team setup JSON** pointed at the wrong plugin key.
## Changes
- Leads with what the plugin does: act on 1,000+ apps from Claude Code
with fully managed OAuth — no API keys, no config files.
- Install is two slash commands, then "ask Claude to do something": on
first use Claude installs the Composio CLI if it's missing (behind the
normal permission prompt), signs you in, and hands you an OAuth link for
the app. Manual CLI setup stays as an optional ahead-of-time note.
- "What you can do" examples: single-app, cross-app workflow, parallel
reads + summary.
- `/composio-connect <app>` documented as the way to connect apps
proactively.
- Keeps team setup (corrected `composio@composio` key), updating,
source-code link, and a lean troubleshooting section (plugin issues →
Claude Code plugin docs; everything else → `composio --help` / CLI
reference).
- A one-line Callout routes Cursor/Codex/Claude Desktop/MCP-client users
to `/docs/composio-connect`.
`bun run lint:links` passes; eslint findings are pre-existing on `next`
and untouched by this change. No `meta.json` change — the page was
already removed from the sidebar in #3455 and remains routable at the
same URL.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
## Summary
`composio whoami` reports the wrong organization after `composio orgs
switch`.
It always shows the API key's home org, ignoring the switched-to org,
even
though `composio orgs list` correctly reflects the selection.
**Root cause:** `whoami` resolves session info via
`getSessionInfoByUserApiKey`,
which sent only `x-user-api-key` and omitted `x-org-id`. Without that
header the
backend falls back to the API key's home org. Consumer commands
(`search`,
`execute`, …) already forward the selected org via
`resolveCommandProject`, so
only `whoami` was affected — a display bug, not an API bug.
**Verification that the backend honors the header** (direct calls to
`GET /api/v3/auth/session/info`):
| `x-org-id` | returned project/org |
|---|---|
| org A | org A |
| org B | org B |
| (omitted) | API key's home org |
## Changes
- `getSessionInfoByUserApiKey` accepts an optional `orgId` and forwards
it as
`x-org-id` when present (login-time callers pass none, so their behavior
is
unchanged).
- `whoami` passes the selected global org (`ctx.data.orgId`).
- Unit tests asserting the header is sent when an org is selected and
omitted
otherwise.
## Type of change
- [x] Bug fix
## How Has This Been Tested?
- New unit tests: `test/src/services/composio-clients.test.ts` (2
cases).
- Existing `whoami.cmd.test.ts` still passes (5 tests total green).
- Manual end-to-end with a real UAK against two orgs: a binary built
from this
branch reports the switched org correctly (`orgs switch` → `whoami`),
whereas the released 0.2.31 binary always reported the home org.
## 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 user-facing docs affected)
- [x] I added tests or explain why not applicable
- [x] I added a changeset if this change affects published packages
Lead with what the plugin does (act on 1,000+ apps, cross-app
workflows, managed OAuth) instead of how it is built. Drop the hook
inventory, no-MCP disclaimers, and the comparison table. Correct the
install story: the CLI is not a manual prerequisite — Claude installs
it and walks through login and app OAuth on first use; manual setup
stays as an optional note.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The plugin was redesigned from an MCP-server bundle to a thin CLI-based
plugin; the page still documented the old design — a nonexistent install
command (composio-mcp@composio) and bundled skills that no longer exist.
Rewrite the page around what actually ships: SessionStart/UserPromptSubmit
hooks, the /composio-connect command, and the just-in-time
search -> execute flow driven by the composio CLI.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This PR:
- unblocks #3820 — the `0.14.0` release train (including
`@composio/experimental@0.2.0` with the `./eve` export) is versioned on
`next` but was never published to npm
- deletes `.changeset/cli-file-upload-denylist.md`: it targets
`@composio/cli`, which is in the changesets `ignore` list (since #3676),
so `changeset version` never consumes it
- the leftover changeset makes `changesets/action` pick version-PR mode
over publish mode on every push to `next`, then fail with `No commits
between next and changeset-release/next` because the versioning no-ops —
see the [failed
run](https://github.com/ComposioHQ/composio/actions/runs/29449907252/job/87469539026);
the publish step never executes
- ports the security note from the deleted changeset into the `0.3.0`
section of `ts/packages/cli/CHANGELOG.md` — the fix commit (fc17c37bf,
#3763) is part of the `0.3.0` tree, and `@composio/cli@0.3.0` has no
tag/release yet
## Context
Once this merges, the next `TS SDK Release` run on `next` will find no
pending changesets, take the publish path (`pnpm changeset:release`),
and push the pending versions to npm.
Follow-up worth considering (not in this PR): a CI check that rejects
changesets referencing packages in the `ignore` list, since any such
changeset permanently wedges the release train.
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.14.0
### Minor Changes
- fc17c37: Export the sensitive-file-upload denylist guard from the
package root so downstream packages share one implementation:
`assertSafeFileUploadPath`, `isBlockedSensitiveFileUploadPath`, and
`BUILTIN_FILE_UPLOAD_PATH_DENY_SEGMENTS`. The guard now routes its
filesystem access through the internal `#platform` abstraction (adding a
`realpathSync` platform method), so it is edge/workerd-safe and the
module carries no static `node:*` imports. Behavior on Node/Bun is
unchanged.
- 20a4711: `triggers.create` now resolves the connection from `user_id`
on the backend instead of client-side.
- The SDK no longer makes an extra `connectedAccounts.list()` call. When
`connectedAccountId` is omitted, the backend resolves the first active
connection for the user and the trigger's toolkit (ordered by most
recently created), matching tool execution.
- **Behavior change:** `create` no longer throws
`ComposioConnectedAccountNotFoundError` for a missing or invalid
connection. That case now surfaces as the backend error from the upsert
call. `ComposioTriggerTypeNotFoundError` (invalid slug) and
`ValidationError` (including empty `userId`) are still thrown
client-side.
- **Requires a backend that resolves the trigger connection from
`user_id` on upsert**
([ComposioHQ/platform#10932](https://github.com/ComposioHQ/platform/pull/10932)).
Self-hosted deployments must be on a version that includes it.
### Patch Changes
- 7125576: Normalize duplicate JSON Schema `required` entries before
provider tool schemas are emitted.
- 58bc93b: Refresh dependency ranges and lockfiles across the workspace.
- 4c3a321: Disable client retries on `tools.execute` and
`tools.proxyExecute`. These are non-idempotent writes, so a silent retry
after a read timeout could duplicate the side effect (e.g. send the same
email more than once). Both now route through a sibling client built
with `maxRetries: 0`; reads keep the default retry behaviour.
- b07fcad: Add an eve provider: `EveProvider` makes `session.tools()`
return eve-native `defineTool`s, `defineComposioTools` is the
replay-safe `step.started` resolver, and `(ctx, next)` hooks can
rewrite, deny, or transform Tool Router meta-tool calls.
Preserve successful local-tool results when the remote half of a mixed
`COMPOSIO_MULTI_EXECUTE_TOOL` batch fails at the transport layer, so
callers can see which side effects already completed before retrying.
- fa933a6: Fix the `homepage` links in these packages' `package.json`.
They pointed at `github.com/ComposioHQ/composio/tree/main/...`, but the
default branch is `next` and no `main` branch exists, so every link
404'd on npm and in editor tooltips. They now point at `tree/next/...`.
- 2ef40ce: Treat local file paths that begin with `http` as paths
instead of URLs, ensuring that upload allowlist and sensitive-file
denylist checks still run.
- e78ed31: Execute every parallel tool call in
`OpenAIProvider.handleToolCalls`. It previously only ran the first tool
call in each assistant message, so parallel tool calls (on by default)
dropped the rest and left their `tool_call_id`s unanswered, failing the
next request.
The calls are run sequentially, in the order the model returned them —
here "parallel" means the model issued several calls in one turn, not
that they execute concurrently — so each `tool_call_id` is answered
exactly once and the tool messages come back in a deterministic order.
Only the first choice is handled. Tool results are fed back into a
single assistant turn, so with `n > 1` iterating over every choice would
run each tool call once per choice and orphan the `tool_call_id`s from
the alternative completions.
- a0f37a7: Close two secret/SSRF exposure surfaces in the TypeScript
SDK:
- **SSRF guard on URL file inputs.** `composio.files.upload(url)` and
automatic file upload during tool execution previously did a raw
`fetch()` on user-supplied URLs with no guard. They now resolve the host
and refuse private, loopback, link-local (incl. the `169.254.169.254`
cloud-metadata endpoint), CGNAT, and reserved addresses, reject
non-`http(s)` schemes, and follow redirects manually so each hop is
re-validated (blocking a public URL that redirects into internal space).
Blocked requests throw `ComposioBlockedInternalUrlError`. Node-only;
behaviour for public URLs is unchanged.
- **Telemetry redaction.** Error telemetry previously shipped
`error.message` / `error.stack` verbatim. They are now passed through a
redactor that strips URL query strings, `Authorization` bearer/basic
credentials, and secret-like `key=value` pairs (API keys, tokens, client
secrets, passwords) before transport.
- 820abb9: Resolve toolkit version pins case-insensitively. Version maps
are keyed by normalized (lowercase) slugs, but `getToolkitVersion`
previously looked them up with the raw slug, so a pin configured under a
different casing (e.g. `{ GitHub: '20250101_00' }` or
`COMPOSIO_TOOLKIT_VERSION_GITHUB`) could silently fall back to
`'latest'`. Normalization is now centralized in a single
`normalizeToolkitSlug` helper used symmetrically on both the write
(map-building) and read (lookup) paths, so the two sides can no longer
drift. This mirrors the equivalent fix in the Python SDK.
- Updated dependencies [58bc93b]
- Updated dependencies [fa933a6]
- @composio/json-schema-to-zod@0.2.1
## @composio/experimental@0.2.0
### Minor Changes
- b07fcad: Add an eve provider: `EveProvider` makes `session.tools()`
return eve-native `defineTool`s, `defineComposioTools` is the
replay-safe `step.started` resolver, and `(ctx, next)` hooks can
rewrite, deny, or transform Tool Router meta-tool calls.
Preserve successful local-tool results when the remote half of a mixed
`COMPOSIO_MULTI_EXECUTE_TOOL` batch fails at the transport layer, so
callers can see which side effects already completed before retrying.
### Patch Changes
- 58bc93b: Refresh dependency ranges and lockfiles across the workspace.
- fa933a6: Fix the `homepage` links in these packages' `package.json`.
They pointed at `github.com/ComposioHQ/composio/tree/main/...`, but the
default branch is `next` and no `main` branch exists, so every link
404'd on npm and in editor tooltips. They now point at `tree/next/...`.
## @composio/json-schema-to-zod@0.2.1
### Patch Changes
- 58bc93b: Refresh dependency ranges and lockfiles across the workspace.
- fa933a6: Fix the `homepage` links in these packages' `package.json`.
They pointed at `github.com/ComposioHQ/composio/tree/main/...`, but the
default branch is `next` and no `main` branch exists, so every link
404'd on npm and in editor tooltips. They now point at `tree/next/...`.
## @composio/anthropic@0.10.1
### Patch Changes
- 7125576: Normalize duplicate JSON Schema `required` entries before
provider tool schemas are emitted.
- 58bc93b: Refresh dependency ranges and lockfiles across the workspace.
- fa933a6: Fix the `homepage` links in these packages' `package.json`.
They pointed at `github.com/ComposioHQ/composio/tree/main/...`, but the
default branch is `next` and no `main` branch exists, so every link
404'd on npm and in editor tooltips. They now point at `tree/next/...`.
## @composio/claude-agent-sdk@0.10.1
### Patch Changes
- 58bc93b: Refresh dependency ranges and lockfiles across the workspace.
- fa933a6: Fix the `homepage` links in these packages' `package.json`.
They pointed at `github.com/ComposioHQ/composio/tree/main/...`, but the
default branch is `next` and no `main` branch exists, so every link
404'd on npm and in editor tooltips. They now point at `tree/next/...`.
## @composio/cloudflare@0.10.1
### Patch Changes
- 7125576: Normalize duplicate JSON Schema `required` entries before
provider tool schemas are emitted.
- fa933a6: Fix the `homepage` links in these packages' `package.json`.
They pointed at `github.com/ComposioHQ/composio/tree/main/...`, but the
default branch is `next` and no `main` branch exists, so every link
404'd on npm and in editor tooltips. They now point at `tree/next/...`.
## @composio/google@0.10.1
### Patch Changes
- 7125576: Normalize duplicate JSON Schema `required` entries before
provider tool schemas are emitted.
- fa933a6: Fix the `homepage` links in these packages' `package.json`.
They pointed at `github.com/ComposioHQ/composio/tree/main/...`, but the
default branch is `next` and no `main` branch exists, so every link
404'd on npm and in editor tooltips. They now point at `tree/next/...`.
## @composio/langchain@0.10.1
### Patch Changes
- 58bc93b: Refresh dependency ranges and lockfiles across the workspace.
- fa933a6: Fix the `homepage` links in these packages' `package.json`.
They pointed at `github.com/ComposioHQ/composio/tree/main/...`, but the
default branch is `next` and no `main` branch exists, so every link
404'd on npm and in editor tooltips. They now point at `tree/next/...`.
## @composio/llamaindex@0.10.1
### Patch Changes
- fa933a6: Fix the `homepage` links in these packages' `package.json`.
They pointed at `github.com/ComposioHQ/composio/tree/main/...`, but the
default branch is `next` and no `main` branch exists, so every link
404'd on npm and in editor tooltips. They now point at `tree/next/...`.
## @composio/mastra@0.10.2
### Patch Changes
- 58bc93b: Refresh dependency ranges and lockfiles across the workspace.
- fa933a6: Fix the `homepage` links in these packages' `package.json`.
They pointed at `github.com/ComposioHQ/composio/tree/main/...`, but the
default branch is `next` and no `main` branch exists, so every link
404'd on npm and in editor tooltips. They now point at `tree/next/...`.
## @composio/openai@0.10.1
### Patch Changes
- 7125576: Normalize duplicate JSON Schema `required` entries before
provider tool schemas are emitted.
- fa933a6: Fix the `homepage` links in these packages' `package.json`.
They pointed at `github.com/ComposioHQ/composio/tree/main/...`, but the
default branch is `next` and no `main` branch exists, so every link
404'd on npm and in editor tooltips. They now point at `tree/next/...`.
## @composio/openai-agents@0.10.1
### Patch Changes
- 7125576: Normalize duplicate JSON Schema `required` entries before
provider tool schemas are emitted.
- 58bc93b: Refresh dependency ranges and lockfiles across the workspace.
- fa933a6: Fix the `homepage` links in these packages' `package.json`.
They pointed at `github.com/ComposioHQ/composio/tree/main/...`, but the
default branch is `next` and no `main` branch exists, so every link
404'd on npm and in editor tooltips. They now point at `tree/next/...`.
## @composio/vercel@0.11.1
### Patch Changes
- fa933a6: Fix the `homepage` links in these packages' `package.json`.
They pointed at `github.com/ComposioHQ/composio/tree/main/...`, but the
default branch is `next` and no `main` branch exists, so every link
404'd on npm and in editor tooltips. They now point at `tree/next/...`.
## @composio/slim@0.14.0
### Patch Changes
- 58bc93b: Refresh dependency ranges and lockfiles across the workspace.
- fa933a6: Fix the `homepage` links in these packages' `package.json`.
They pointed at `github.com/ComposioHQ/composio/tree/main/...`, but the
default branch is `next` and no `main` branch exists, so every link
404'd on npm and in editor tooltips. They now point at `tree/next/...`.
- Updated dependencies [58bc93b]
- Updated dependencies [fa933a6]
- @composio/json-schema-to-zod@0.2.1
## @composio/cli-keyring@0.2.1
### Patch Changes
- 58bc93b: Refresh dependency ranges and lockfiles across the workspace.
## @composio/ts-builders@0.2.1
### Patch Changes
- 58bc93b: Refresh dependency ranges and lockfiles across the workspace.
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
This PR:
- builds on https://github.com/ComposioHQ/composio/pull/3823 and
https://github.com/ComposioHQ/composio/pull/3824
- bumps the Python SDK and every provider package from `0.17.1` to
`0.18.0`
- synchronizes the runtime version and root `uv.lock`
- adds the canonical July 16 changelog entry, including URL-upload and
telemetry security, trigger connection-resolution behavior, provider
schema fixes, and the `pyautogen` to `ag2` migration
- strengthens release guards for Python workflow invocation, provider
metadata, and current Python and TypeScript changelog coverage
- limits provider packaging to directories containing `pyproject.toml`
- makes provider cleanup, installation, and builds stop on the first
failure
- incorporates the merged TypeScript changelog and missing Changeset
from https://github.com/ComposioHQ/composio/pull/3849
After merging, create and push the annotated `py@0.18.0` tag from the
merged `next` commit.
## Validation
- `pnpm test:release-workflow`
- `uv lock --check`
- `uv run --frozen python -c "import composio; assert
composio.__version__ == \"0.18.0\""`
- `pnpm exec prettier --check
docs/content/changelog/07-16-26-python-sdk-018.mdx
test/release-workflow.test.ts`
- `cd docs && bun run test`
- `cd docs && bun run lint:links`
- `cd docs && bun run types:check`
- `cd python && make build`
- `cd python && uv tool run twine check dist/*`
This PR:
- documents TypeScript `@composio/core` `0.14.0`, prepared in
https://github.com/ComposioHQ/composio/pull/3717
- calls out trigger behavior changes, provider compatibility,
file-upload security, telemetry redaction, and tool-execution
reliability
- adds the missing `@composio/core` patch Changeset for the local-path
fix merged in https://github.com/ComposioHQ/composio/pull/3766
- leaves the Python `0.18.0` changelog with
https://github.com/ComposioHQ/composio/pull/3825 so the release and docs
PRs do not add the same file
- keeps the TypeScript candidate release in the canonical docs changelog
before publishing
After this PR merges into `next`, the Changesets release PR must
regenerate before publishing.
## Validation
- `pnpm test:release-workflow`
- `pnpm changeset status --since=origin/next`
- `bun run test`
- `bun run lint:links`
- `bun run types:check`
- `bun run build`
- `pnpm exec prettier --check
docs/content/changelog/07-15-26-typescript-sdk-014.mdx
.changeset/http-prefixed-local-paths.md`
`bun run lint` remains red on 23 existing React and Next.js errors
outside these files.
`_type_to_parameter` in `python/composio/utils/openapi.py` assumed a
property's
`type` was a scalar string. JSON Schema Draft 2020-12 and OpenAPI 3.1
can express
a nullable field as a list of types instead, for example
`{"type": ["string", "null"]}`. Passing that list to the scalar
membership check
raised `TypeError: unhashable type: 'list'`, which could break tool
signature
generation in providers such as `google_adk`.
## Changes
- Handle list-valued `type` definitions as unions.
- Re-run every member through `_type_to_parameter` with a copy of the
full
property schema and only `type` replaced. This preserves sibling fields
such
as an array's `items`, so `{"type": ["array", "null"], "items": ...}`
resolves
to `Optional[List[...]]`.
- Preserve scalar error behavior for invalid member types: an unknown
type in a
list raises `InvalidSchemaError` instead of silently becoming `Any`.
- Keep the existing empty-list fallback to `Any`.
- Add regression coverage for nullable arrays and scalar/list
unknown-type
parity alongside the existing list-valued type cases.
## Type of change
- [x] Bug fix
- [ ] New feature
- [ ] Refactor/Chore
- [ ] Documentation
- [ ] Breaking change
## Verification
From `python/`:
- `uv run pytest tests/test_openapi.py -q` — 18 passed.
- `make chk` — Ruff and mypy passed across the Python SDK, providers,
tests,
examples, and scripts.
## 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 (not applicable: internal
helper)
- [x] I added regression tests
- [ ] I added a changeset (not applicable: Python-only change)
---------
Signed-off-by: Anas Khan <83116240+anxkhn@users.noreply.github.com>
Signed-off-by: jkomyno <alberto@composio.dev>
Co-authored-by: jkomyno <alberto@composio.dev>
## Summary
The LangGraph Python example imports from langchain.agents import
create_agent, but the install command on the same page doesn't include
langchain — and neither langgraph nor langchain_openai pulls it in (they
only depend on langchain-core). Following the docs verbatim in a fresh
environment fails on the example's first import with
ModuleNotFoundError: No module named 'langchain'.
Fixes#3847
## Changes
- docs/content/docs/providers/langchain.mdx: LangGraph Python install
line gains langchain, matching the provider's own README
(python/providers/langgraph/README.md).
## Type of change
- [ ] Bug fix
- [ ] New feature
- [ ] Refactor/Chore
- [x] Documentation
- [ ] Breaking change
## How Has This Been Tested?
- Fresh venv with the documented install set (langgraph==1.2.9,
langchain-openai==1.3.5, Python 3.12): from langchain.agents import
create_agent fails with ModuleNotFoundError.
- Same venv after adding langchain: the docs example constructs the
agent via create_agent and the wrapped tool invokes correctly, with no
deprecation warnings.
- Docs: bun run build and bun run lint:links from docs/: green.
## 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
- [ ] I added tests or explain why not applicable
- [x] I added a changeset if this change affects published packages
## Additional context
No changeset: docs-only. No tests: one-word install-command fix,
verified manually as above.
## Summary
Prevent the Python OpenAI Agents provider from rewriting valid JSON
Schema array item definitions.
- Stop adding `"type": "string"` when an `items` schema has no direct
`type`.
- Preserve item schemas using `anyOf`, `oneOf`, `$ref`, object
constraints, or `{}`.
- Continue removing `examples`, `pattern`, and `default` as before.
- Add regression coverage for each affected schema shape.
## Problem
The provider previously added `"type": "string"` to every array `items`
object without a direct
type declaration.
That changes the meaning of valid JSON Schemas. For example:
```json
{
"anyOf": [
{ "type": "object" },
{ "type": "null" }
]
}
became:
{
"type": "string",
"anyOf": [
{ "type": "object" },
{ "type": "null" }
]
}
Because both constraints apply, valid object and null values become
impossible. This could expose
misleading tool schemas to OpenAI Agents or cause correct tool arguments
to be rejected.
## Testing
- OpenAI Agents provider tests — 6 passed
- OpenAI Agents type-inference tests — 5 passed
- Mypy passed
- Ruff lint and formatting passed
- Schema-preservation smoke test passed
Co-authored-by: GautamSharma99 <gautamsharme99067@gmail.com>
Co-authored-by: Alberto Schiabel <jkomyno@users.noreply.github.com>
## Summary
Deprecated REST endpoints now surface the existing `Legacy` badge in
generated API-reference indexes, with endpoint-specific tooltip copy
instead of the Sessions-specific default. The generator behavior is
covered end to end for both v3 and v3.1, including rendered table
output.
This branch also restores CI compatibility with the organization Actions
policy: workflow tool versions still come from `mise.toml`, but
installation uses the approved, SHA-pinned setup actions. Secret
scanning pins the repaired organization reusable workflow from
ComposioHQ/.github#13.
## Changes
- Read the OpenAPI `deprecated` flag and emit `legacy: true` only for
deprecated operations.
- Render `LegacyBadge` on affected endpoint rows with accurate lifecycle
tooltip copy.
- Regenerate the affected `files` and `connected-accounts` indexes for
v3 and v3.1.
- Cover the real generator output, active-operation omission, badge
count, and tooltip through a focused regression test.
- Replace disallowed transitive Actions dependencies while retaining
`mise.toml` as the single tool-version source.
Endpoint detail pages continue to use `fumadocs-openapi`'s built-in
deprecated marker. The indexed endpoints are `GET /files/list` and `POST
/connected_accounts/{nanoid}/refresh`; internal operations remain
filtered from the docs.
## Spec data
The committed OpenAPI snapshots lagged the live backend for `POST
/connected_accounts/{nanoid}/refresh`. Both snapshots now carry its
current summary, description, and `deprecated: true`; the next
`fetch-openapi.mjs` run will preserve that state from the live spec.
## Validation
- `bun run test`: 25 passed, 0 failed.
- `bun run types:check`: passed.
- Focused ESLint and generated-index drift checks: clean.
- Composite-action and workflow YAML parsed successfully; extracted tool
pins match `mise.toml`.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
---------
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Co-authored-by: jkomyno <alberto@composio.dev>
## What this fixes
This is a follow-up to #3770, not a second root-cause fix.
#3770 moved the docs data workflow from staging to production,
centralized the production API URL, removed staging hosts from the
committed data, and added the hostname guard. The committed toolkit
catalog still retained staging-derived `version` values, however,
because that PR intentionally did not regenerate the full catalog. After
#3770 merged, the scheduled production regeneration began failing with
`401 Unauthorized`: the repository's existing `COMPOSIO_API_KEY` secret
is staging-scoped.
The customer-visible result was that nearly every toolkit page showed
the internal staging version `20260703_00`; Gmail's production version
was `20260702_01`.
## Changes
- Correct every `version` in `docs/public/data/toolkits.json` from the
production toolkit changelog. Toolkits absent from that changelog
receive `null`, matching the full generator's semantics. No other JSON
field changes.
- Move production changelog fetching and version application into shared
`toolkit-versions.ts` logic used by the full catalog generator.
- Add `bun run generate:toolkit-versions` as the narrow, reproducible
generator for version-only repairs.
- Reject any non-production `COMPOSIO_API_BASE` in the toolkit and
meta-tool generators before a request is made.
- Keep the version-distribution check as a smoke signal for the known
whole-catalog staging-bump pattern, while testing the production source
boundary separately. The distribution heuristic is no longer described
as proof of provenance.
- Fail before writing when the production changelog response is
malformed or contains no versions.
## CI policy compatibility
- Replace the enterprise-blocked mise action with allowlisted tool setup
actions while continuing to resolve exact versions from mise.lock.
Install the existing pinned mise CLI release through a checksum-verified
repository script for lock freshness and preinstall validation.
- Run the existing GitHub Advanced Security alert check locally and
notify Slack through the already-allowlisted Slack action, avoiding the
central workflow dependency rejected by the enterprise action policy.
## Verification
- `bun test tests/static/` — 30 passed.
- Targeted ESLint for every changed script/test — passed.
- `bun run types:check` — passed.
- `bun run build` — passed.
- Explicit staging override of `generate-toolkits.ts` — rejected before
network access.
- Verified the JSON data change remains version-only; toolkit ordering,
tools, triggers, descriptions, and counts are unchanged.
## Remaining deployment action
An administrator still needs to replace `COMPOSIO_API_KEY` with a
production-scoped key. The scheduled `docs-update-data` workflow is
correctly pinned to production and therefore fails loudly with the
current staging credential instead of republishing staging data. Once
the secret is corrected, the normal full-catalog generator remains the
authoritative refresh path.
Triggered by: abhishek@composio.dev | Source: slack
Session: https://zen.corp.composio.io/dashboard/#/chat/zen-3a77f73eb146
---------
Co-authored-by: Zen Agent <zen@composio.dev>
Co-authored-by: abhishek <abhishek@composio.dev>
Co-authored-by: jkomyno <alberto@composio.dev>
## Summary
The Gemini Python example paired composio_google (which wraps tools as
VertexAI FunctionDeclaration objects) with google-genai client.
GenerateContentConfig silently coerces those VertexAI objects into an
empty genai Tool ({}), so the documented flow sends requests with no
tool schemas at all - the model never sees or calls any Composio tool,
with no error surfaced anywhere.
Fixes#3836
## Changes
- docs/content/docs/providers/google.mdx (Gemini tab, Python only):
- install line: composio_google → composio_gemini
- example: GeminiProvider + Automatic Function Calling; the manual while
response.function_calls: loop is gone because the google-genai SDK
executes the wrapped callables itself
- intro paragraph updated to describe the Python (AFC) and TypeScript
(manual loop) flows separately
The TypeScript tab and the Google ADK section are untouched; both
already target the right SDKs. The new Python example matches the
existing quickstart in python/providers/gemini/README.md.
## Type of change
- [ ] Bug fix
- [ ] New feature
- [ ] Refactor/Chore
- [x] Documentation
- [ ] Breaking change
## How Has This Been Tested?
- Offline repro of the bug (issue #3836): with composio_google,
config.tools[0].model_dump(exclude_none=True) is {} and genai's
_transformers.t_tools raises AttributeError on the vertexai type.
- Offline verification of the fix: the exact construction path of the
new example (GeminiProvider().wrap_tools → GenerateContentConfig →
chats.create → t_tools) serializes a complete FunctionDeclaration (name,
description, parameters) with composio==0.17.1, google-genai==2.11.0,
Python 3.12.
- Docs: bun run build and bun run lint:links from docs/: green.
## 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
No changeset: docs-only change, no published package affected.
Regression coverage: `docs/tests/static/content.test.ts` now guards the
documented `composio_gemini` + `google-genai` pairing; the example's
construction path was also exercised offline as described above.
The underlying provider split (composio_google targeting the
upstream-deprecated vertexai generative_models SDK vs composio_gemini
targeting google-genai) is flagged in #3836 as an open question for
maintainers; this PR is the docs-only fix.
---------
Co-authored-by: jkomyno <alberto@composio.dev>
## Summary
- classify detected Claude Code and Codex hosts as supported or
unsupported before plugin inspection
- verify both marketplace and plugin-list JSON capabilities; retain the
Codex 0.139.0 minimum
- in automatic mode, skip unsupported hosts and continue with supported
hosts
- honor `--if-present` when automatic detection leaves only unsupported
hosts
- fail before mutation when no supported host remains without
`--if-present`, or when an unsupported host is explicitly targeted
- turn expected setup, inspection, install, verification, and uninstall
failures into concise setup-specific errors with recovery commands
- keep failures nonzero while avoiding generic Effect diagnostics and
command-usage dumps
## Deferred follow-up
Install/setup/plugin lifecycle telemetry and direct PostHog delivery are
intentionally out of scope for this compatibility PR. They will be
implemented separately so anonymous first-install events have a working
delivery path.
## Regression coverage
- unit coverage exercises supported and unsupported Claude/Codex
combinations, explicit targets, `--if-present`, safe preflight, native
failures, timeouts, malformed responses, and verification failures
- Debian CLI E2E covers both unsupported-host directions,
unsupported-only `--if-present`, and packaged noninteractive failures
with concise output
- a fresh isolated macOS HOME matrix covers 16 host/state scenarios
using the exact standalone binary, real skill ZIP installation from a
localhost fixture, PTY transcripts, idempotence, uninstall, and
reinstall
## Verification
- `pnpm --filter @composio/cli test`: 781 passed, 1 skipped across 83
files
- `pnpm typecheck`: 12 tasks passed
- `bash test/install-sh-release-resolution.test.sh`: passed
- `pnpm --filter @e2e-tests/cli-setup-plugins test:e2e:cli`: 11 passed
in a rebuilt Debian image
- fresh isolated macOS HOME/PTY matrix: 16/16 passed
- `git diff --check`: passed
No changeset: this remains an unreleased CLI compatibility change;
stable promotion is separate.
This PR:
- supersedes https://github.com/ComposioHQ/composio/pull/3807 while
preserving Kshitij's original commits and authorship
- lets users configure the public Composio plugin for Claude Code,
Codex, or every detected host with `composio setup`
- centralizes host-specific commands, JSON keys, scope rules, and skill
policy in a typed adapter map
- requires explicit `--yes` approval outside an interactive terminal and
keeps action-command stdout empty
- accepts only canonical HTTPS marketplace sources, requires Claude's
user-scoped plugin, and verifies a readable release-matched skill
- preflights every selected host before mutation, reinstalls plugins
after marketplace repair, and reports partial completion if a later host
fails
- fails closed on native inspection errors or malformed JSON and bounds
host subprocesses to two minutes
- verifies final native state so successful subprocess exits cannot
masquerade as a ready setup
- uses Effect filesystem and path services throughout the touched
installer source and tests
## Validation
- `pnpm typecheck`: 12 tasks passed across the TypeScript workspace
- `pnpm --filter @composio/cli test`: 83 files passed; 760 tests passed;
1 skipped
- focused installer regressions: 18 passed
- focused ESLint, direct `node:fs` / `node:path` audit, and `git diff
--check`: clean
- Docker CLI E2E: Claude and Codex install once, remain idempotent on
rerun, and fail clearly when no host is available
## Known release artifact
The VHS recording remains deferred until the clean-home real-host smoke
test because recording this workflow mutates external agent-host state.
The deterministic Docker E2E covers the packaged CLI boundary in the
meantime.
## Summary
- run plugin setup automatically from the canonical `install.sh` flow
after shell integration
- configure every detected Claude Code and Codex host through the setup
engine from #3835
- add `composio setup --if-present` so installer automation succeeds
when no supported host is installed
- support `--no-plugins` and `COMPOSIO_INSTALL_PLUGINS=0` as explicit
opt-outs
- fail visibly with an exact retry command when a detected host cannot
be configured
## Stack
This is a deliberately small follow-up to #3835 and targets
`jk/cli-plugin-setup-review`. It should be rebased onto `next` after
#3835 merges.
## Behavior
The installer invokes the newly installed binary directly, so it does
not depend on the current shell reloading `PATH`:
```bash
"$exe" setup --target auto --yes --if-present
```
No detected host is a successful no-op. A detected host setup failure
leaves the CLI installed but fails the installer with `composio setup
--target auto --yes` as the retry path.
## Validation
- install.sh release-resolution, automatic setup, opt-out, and
setup-failure harness passed
- focused setup suite: 25 tests passed
- full CLI suite: 83 files passed; 761 tests passed; 1 skipped
- direct CLI source and test typechecks passed
- stable and beta skill validation passed
- focused ESLint, shell syntax checks, and `git diff --check` passed
- packaged setup E2E updated for the no-host installer path; local
launch is blocked by missing `mise`, so scratch-container CI is the
authoritative packaged check
## Recording
No VHS recording: this is installer orchestration plus a non-interactive
automation flag, covered at the shell-installer and packaged CLI
boundaries.
Replace direct Node filesystem and path access throughout the touched installer paths and tests. Preserve cleanup and replacement guarantees with focused lifecycle coverage.
## Summary
The AutoGen provider examples still used the legacy
`llm_config={"config_list": [...]}` dict form, which ag2 0.14 (the
distribution `composio-autogen` depends on since #3729) only keeps for
backport compatibility and marks deprecated in
`LLMConfig.ensure_config`. The install command also pulled
`autogen-agentchat` (Microsoft's next-gen AutoGen package), which the
provider never imports, while the `ag2` distribution the examples
actually import from was only installed transitively.
Fixes#3831
## Changes
- `docs/content/docs/providers/autogen.mdx`: example migrated to
`LLMConfig({...})`, install line changed to `composio composio_autogen
ag2`, added `ag2` keyword and a one-line note that the provider runs on
the ag2 distribution
- `python/providers/autogen/README.md`: same quickstart and install
fixes
- `python/providers/autogen/autogen_demo.py`: same `LLMConfig` migration
`initiate_chat` is left as is: it isn't deprecated in ag2 0.14, and it's
the flow `register_tools` (caller/executor) is verified against.
## Type of change
- [ ] Bug fix
- [ ] New feature
- [ ] Refactor/Chore
- [x] Documentation
- [ ] Breaking change
## How Has This Been Tested?
- Verified in a fresh venv with the local `composio` +
`composio-autogen` packages and `ag2==0.14.0`: the updated example
constructs both agents, wraps a Composio tool via `AutogenProvider`,
registers it with `register_tools`, and executes it through the
executor's function map
- `uv run nox -s chk` (ruff + mypy): green
- `ruff format --check providers/autogen/`: clean
- Docs: `bun run build` and `bun run lint:links` from `docs/`: green
## 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
- [ ] I added tests or explain why not applicable
- [x] I added a changeset if this change affects published packages
## Additional context
No changeset added: docs and Python-only change, no published TypeScript
package affected. No tests added: example/docs change with no runtime
code paths; the updated example was exercised manually against ag2 0.14
as described above.
---------
Co-authored-by: Alberto Schiabel <jkomyno@users.noreply.github.com>
Co-authored-by: jkomyno <alberto@composio.dev>
This PR:
- validates Python package versions and release-note coverage before a
`py@*` tag can build or publish artifacts
- runs the existing repository release-workflow guard in the tag-release
workflow
- installs the pinned Node, pnpm, and Bun toolchain only for the
metadata validation step
- prevents a tag from publishing artifacts whose package, runtime,
provider, or docs versions drift apart
Validation:
- `pnpm test:release-workflow`
- `pnpm exec prettier --check .github/workflows/py.release.yml`
Alberto Schiabel