mirror of
https://github.com/ComposioHQ/composio.git
synced 2026-09-22 11:46:35 +08:00
py@0.18.2
4745 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
|
|
0979159e10 |
refactor(cli): activate the try/catch and env ban and pin the boundary ratchet (#3885)
This PR: - activates the final rule group: `TryStatement` and `process.env` are now ESLint-banned in CLI source, completing the enforcement ramp started in the first PR of this stack; the env guard covers dot access, bracket access, and object destructuring - migrates the residual files (auth-config create, trigger create, toolkit search, runtime debug flags, master detection, import-time UI setup) off try/catch and ad-hoc env reads - every surviving violation sits at a declared runtime boundary (bin.ts bootstrap, child-process companion runtime, import-time UI setup, environment writes and whole-environment enumeration, spawn-time env handshakes) with an inline `// eslint-disable-next-line <rule> -- <reason>` justification - adds `eslint-boundaries.json` — the checked-in manifest of the 46 sanctioned disables across 22 files — and `validate:boundaries` (part of `pnpm test`), which scans both `.ts` and `.tsx` sources and fails on undeclared, missing, relocated, bare, or file-wide disables - pins each registered boundary by rule, justification, and governed next-line target, with regression coverage for TSX discovery, same-file retargeting, and duplicate semantic sites - documents the Effect Boundary Policy in the CLI `AGENTS.md` and the `cli-command` skill reference, and drops the gitleaks test-file allowlist --- **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 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 ← **this PR** 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`. |
||
|
|
aaabe9922b |
refactor(cli): enforce typed Effect error boundaries and v4 readiness seams (#3884)
This PR:
- converts every remaining thunk-form `Effect.tryPromise` in CLI source
to a purpose-named `Data.TaggedError` preserving its cause —
`UnknownException` no longer surfaces from `src/` — and switches
best-effort recoveries from `catchAll` to `catchTag`
- isolates the `Symbol.for('effect/SpanAnnotation')` internal read
behind a shape-validating adapter, with a canary test that fails a real
effect through the runtime so an `effect` upgrade that drops the
mechanism breaks CI instead of silently losing span timelines
- decodes trigger-log payloads once at the API boundary through a
tolerant schema documenting camelCase/snake_case/meta-nested alias
precedence
- deduplicates the per-entry tolerant decoders into
`utils/collect-decoded-entries.ts`, replaces locally re-declared record
schemas with `JsonRecordSchema`, deletes the unused `EnvLangDetector`
service, and removes the temporary sync bridge from the platform-imports
slice
- the largest PR of the stack by design: generic refactors land late so
the fix and rule slices before it stay small; one commit per sub-theme
keeps `git show` reviewable
---
**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
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 ← **this PR**
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`.
|
||
|
|
6010fc712c |
test(cli): lint the test tree and enforce deterministic @effect/vitest suites (#3883)
This PR: - un-ignores `ts/packages/cli/test` in the root ESLint config (fixtures and the `test/__utils__` harness glue stay unlinted) and activates the test rule group: no `Effect.run*` in suites (use `it.effect`/`it.scoped`/`it.live`) and no `Date.now()` - adds `test/__utils__/vitest.setup.ts`, pointing HOME and `COMPOSIO_CACHE_DIR` at per-run temp directories so suites never touch the developer's real `~/.composio` state - migrates the remaining suites onto @effect/vitest runners with layer-provided platforms, pins wall-clock reads via `vi.setSystemTime`/TestClock-relative fixtures, and uses `crypto.randomUUID()` for unique temp names - lands the v3 Cause characterization suite pinning `reduceWithContext` traversal over the six-constructor tree and rendered error output — the executable equivalence oracle for the effect v4 migration - tests arriving in later stack PRs must comply from birth --- **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 7. https://github.com/ComposioHQ/composio/pull/3883 — test-tree lint + deterministic suites ← **this PR** 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`. |
||
|
|
6d5465acd3 |
refactor(cli): seal the CommandDescriptor seam and drop zod for Schema (#3882)
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`.@composio/json-schema-to-effect-schema@0.1.0 |
||
|
|
5318f60de9 |
refactor(cli): route terminal output through the TerminalUI boundary (#3881)
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`. |
||
|
|
4e26d36fd4 |
refactor(cli): migrate platform access to @effect/platform services (#3880)
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`. |
||
|
|
377de97293 |
fix(cli): fail closed on permission gaps and tolerate skewed payloads (#3879)
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`.@composio/cli@0.2.33-beta.298 |
||
|
|
2dc9ef34d0 |
fix(cli): remove new Function() eval from JSON-ish input parsing (#3878)
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`.
@composio/cli@0.2.33-beta.297
|
||
|
|
3c7a6c6c91 |
chore(cli): land Effect-first guidelines and inert guardrail rule groups (#3877)
This PR: - opens the CLI Effect-guardrails stack that re-slices https://github.com/ComposioHQ/composio/pull/3859 into reviewable PRs - rewrites the CLI `AGENTS.md` Effect guidance: typed `Data.TaggedError` failures, `Schema`/`Predicate` decoding at trust boundaries, and Effect platform services over Node builtins — policy for new code effective now - adds the matching "Effect Platform Boundaries" section to the `cli-command` skill reference - defines every new ESLint rule group (platform imports, terminal streams, descriptor seam, zod ban, test rules, try/catch + `process.env`) as live constants in the root `eslint.config.mjs`, with the entries applying them commented out and annotated with the stack PR that activates each group - bumps the vendored `ts/vendor/effect` reference to the pin used across the stack (CI never initializes submodules) No CLI source is touched; `pnpm lint` stays green with the rules inert. --- **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 ← **this PR** 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 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`.@composio/cli@0.2.33-beta.296 |
||
|
|
1d651b5c85 |
docs: remove stale DiscordBot 401 FAQ (#3888)
# 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>
|
||
|
|
9498679c26 |
fix(release): guard and document CLI releases (#3895)
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@composio/cli@0.2.33-beta.295 |
||
|
|
c34401e355 |
docs: rewrite Claude Code plugin page for the CLI-based plugin (#3863)
## 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) |
||
|
|
ecaf737661 | Merge branch 'next' into docs/claude-code-plugin-cli-rewrite | ||
|
|
8467efdfb9 |
fix(cli): whoami respects the org selected via orgs switch (#3832)
## 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@composio/cli@0.2.33-beta.293 |
||
|
|
514d755cdf |
docs: tighten first-run and troubleshooting wording
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
|
e54b215b1f |
docs: make the Claude Code plugin page benefit-first
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> |
||
|
|
3b758a0e29 |
docs: rewrite Claude Code plugin page for the CLI-based plugin
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> |
||
|
|
ac7ca020da |
fix(release): drop stale changeset for ignored @composio/cli (#3861)
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 (
@composio/experimental@0.2.0
@composio/anthropic@0.10.1
@composio/core@0.14.0
@composio/vercel@0.11.1
@composio/openai@0.10.1
@composio/claude-agent-sdk@0.10.1
@composio/openai-agents@0.10.1
@composio/cloudflare@0.10.1
@composio/slim@0.14.0
@composio/mastra@0.10.2
@composio/llamaindex@0.10.1
@composio/langchain@0.10.1
@composio/ts-builders@0.2.1
@composio/cli-keyring@0.2.1
@composio/google@0.10.1
@composio/json-schema-to-zod@0.2.1
@composio/cli@0.2.33-beta.292
|
||
|
|
26f3c626e9 |
Release: update version (#3717)
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 - |
||
|
|
facd40258c |
chore(py): prepare 0.18.0 release (#3825)
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/*`py@0.18.0 |
||
|
|
2ef40ce6da |
docs: document TypeScript 0.14.0 release (#3849)
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. |
||
|
|
3b28dc756e |
fix(py): handle list-valued JSON Schema type in openapi signatures (#3822)
`_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>
|
||
|
|
a1d04e19a3 |
docs: add missing langchain to the LangGraph Python install command (#3850)
## 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. |
||
|
|
cb84856a16 |
fix(openai-agents): preserve array item schemas (#3819)
## 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>
|
||
|
|
b9a790ef4e |
docs: tag deprecated API endpoints with the existing Legacy tag (#3838)
## 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> |
||
|
|
4b790dc0ce |
fix(docs): correct toolkit versions and enforce production source (#3837)
## 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>@composio/cli@0.2.33-beta.291 |
||
|
|
183a274d99 |
docs: fix Gemini Python example to use composio_gemini with google-genai (#3839)
## 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>
|
||
|
|
deac5d032d |
fix(cli): handle incompatible Codex plugin commands (#3845)
## 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.@composio/cli@0.2.32-beta.289 @composio/cli@0.2.32 |
||
|
|
333d2296ed | refactor(cli): defer setup telemetry | ||
|
|
4e68e65280 | feat(cli): track plugin setup lifecycle | ||
|
|
20273ea66e | fix(cli): honor if-present for unsupported hosts | ||
|
|
2b375b4855 | fix(cli): handle plugin setup errors gracefully | ||
|
|
460f804dd1 | fix(cli): continue setup with supported hosts | ||
|
|
d004b2a309 | fix(cli): handle incompatible Codex plugin commands | ||
|
|
c7bd7107ff |
feat(cli): install Claude and Codex plugins with composio setup (#3835)
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.@composio/cli@0.2.32-beta.288 |
||
|
|
fb10f57ba7 |
feat(cli): install plugins from the CLI installer (#3840)
## 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. |
||
|
|
cb75ddd02b | fix(cli): preserve unmanaged skills on uninstall | ||
|
|
ca3b25d238 | fix(cli): approve all setup mutations | ||
|
|
c8b1ddeb64 | fix(cli): confirm managed skill removal | ||
|
|
692dec45e7 | fix(cli): preserve explicit setup PATH errors | ||
|
|
f09141455c | fix(cli): require all explicit setup targets | ||
|
|
82341643a4 | feat(cli): add plugin uninstall flow | ||
|
|
b148eda4e6 | fix(cli): prompt only for missing plugins | ||
|
|
b3b3f4efc0 | fix(cli): simplify plugin setup status | ||
|
|
fb5e97749d | feat(cli): install detected agent plugins | ||
|
|
506c402e36 | test(cli): prove plugin setup idempotence | ||
|
|
b953eab001 | Merge branch 'next' into jk/cli-plugin-setup-review | ||
|
|
33b5a2a60a |
refactor(cli): use Effect platform for skill installs
Replace direct Node filesystem and path access throughout the touched installer paths and tests. Preserve cleanup and replacement guarantees with focused lifecycle coverage. |
||
|
|
a14ee316a6 | refactor(cli): use Effect filesystem for setup skill | ||
|
|
b6e7dc5e40 | fix(cli): preserve setup timeout failures |