skills/composiohq__composio
1
0
Fork 0
mirror of https://github.com/ComposioHQ/composio.git synced 2026-09-22 11:46:35 +08:00
Code Issues Packages Projects Releases Wiki Activity
4,620 Commits 338 Branches 1,550 Tags
@composio/cli@0.3.2-beta.335
Commit Graph

4620 Commits

This Branch
This Branch
All Branches
Author SHA1 Message Date
Alberto Schiabel 5630041145 fix(ci): refresh mise.lock for the republished python 3.12.13 build (#4066) 
## Why

`next` is currently red on **Audit Typescript SDK**, and so is every PR
based on it.

`python-build-standalone` republished cpython **3.12.13** under a new
date tag (`20260728` → `20260804`). The pinned version in `mise.toml`
did not change, but `mise lock` now resolves different URLs and
checksums for it. The Audit job runs:

```
mise lock --platform linux-x64,linux-arm64,macos-arm64,macos-x64
git diff --exit-code mise.lock
```

so the committed lockfile no longer matches what `mise lock` produces,
and that step fails on every branch.

Evidence: [Audit on `next` @
`973de6541`](https://github.com/ComposioHQ/composio/actions/runs/31001686227)
— the failing step's diff is exactly the four python entries updated
here.

## What changed

Only the four `[tools.python."platforms.*"]` URL/checksum pairs. No
version pins in `mise.toml` are touched, and no other tool entry moves.

The regenerated checksums match the ones CI computed in the run linked
above, byte for byte.

## Note

Running `mise lock` locally also wanted to append a `[[tools.node]]
version = "24.18.1"` block, picked up from a globally-installed node
rather than from this repo — `mise.toml` pins `node = "24.17.0"`, which
is already locked. That block is deliberately **not** included here.
@composio/cli@0.3.2-beta.335 		2026-08-05 17:52:15 +05:30
jkomyno 2dae4c2541 fix(ci): refresh mise.lock for the republished python 3.12.13 build 
python-build-standalone republished cpython 3.12.13 under the 20260804
tag, so `mise lock` now resolves different URLs and checksums for the
same pinned version. The Audit job regenerates the lockfile and runs
`git diff --exit-code`, so every branch fails that step until the
committed lockfile matches.

Only the four python platform entries change; the pinned versions in
mise.toml are untouched.
 2026-08-05 17:47:54 +05:30
Alberto Schiabel 973de6541d feat(cli): rework composio install PATH setup and add --shell (#4011) 
# fix(cli): rework `composio install` PATH setup

## Why

`composio install` hardcoded `~/.composio` as the directory it added to
`PATH`, and it wrote the block to `~/.bashrc` only. Two consequences: an
installer that puts the entry point somewhere else (a `~/.local/bin`
shim, a version manager's `bin`) had no way to say so, and a login-only
bash shell — `ssh`, `Terminal.app` — never saw the PATH line at all
whenever a `.bash_profile` or `.bash_login` existed to shadow
`.profile`.

This PR makes the target directory a resolved value rather than a
constant, writes to every startup file bash actually reads, and turns
the command into something an installer can call and trust: it either
configures `PATH` or exits non-zero so the caller's own fallback runs.

## What changed

**Bin-dir resolution.** The `PATH` entry now resolves through
`COMPOSIO_BIN_DIR` → `~/.local/bin` when its `composio` entry point
resolves (through symlinks) to the running executable → the running
binary's own directory. A leftover `composio` from another installer no
longer wins the `~/.local/bin` step, so shells are never pointed at a
foreign program.

**`COMPOSIO_BIN_DIR` is public.** It is the user-facing override for the
`PATH` target and the CLI-side contract the mise-style installer will
use, so it is documented in the CLI README with its full resolution
order and named in the `install` command description — `composio install
--help` mentions it. Deliberately no `--bin-dir` flag: the env var is
the right shape for an installer handoff.

**`--shell <zsh|bash|fish>`.** Overrides `$SHELL` detection, for callers
that know which shell they are configuring.

**Bash login files.** The block also lands in `~/.bash_profile` or
`~/.bash_login` when either exists. `.profile` is deliberately not a
candidate: when neither override exists, bash reads `.profile` itself,
and common `.profile` files already source `.bashrc`. The restart hint
now prints `source ~/.bashrc` instead of the literal string `exec
$SHELL`, and mentions the login file when one was written.

**rc file handling.** Writes go through the file's real target, so a
symlinked `.zshrc` keeps its link; the atomic tmp copy is created with
the target's mode from the start, so a private rc's contents never sit
in a world-readable temp file. Two logical paths that alias one physical
file get the block once.

**Managed blocks are reconciled, not just detected.** The marker alone
no longer means "configured": a file is skipped only when it already
contains the exact rendered `PATH` line for the resolved bin dir.
Otherwise the existing managed block is spliced in place — which is what
migrates the legacy three-line block (`export COMPOSIO_INSTALL_DIR=...`
plus a `PATH` line derived from it), written by an older CLI or by
`install.sh`'s fallback, to the current single-line form. A completions
block elsewhere in the file is untouched, and re-running stays
idempotent.

**No reachability skip.** The command used to skip the write entirely
when the bin dir was already on the invoking process's `$PATH`. That is
not evidence about future shells — under an ad-hoc `export` or a
mise/direnv shim it exited 0 having persisted nothing. A
redundant-but-correct `PATH` line is harmless and the content check
already prevents duplicates. The separate early return for "no shell
detected *and* already on `$PATH`" stays (there is no rc file to write
in that case) with wording that says the conclusion came from the
current process.

**Abort contract.** `composio install` aborts, writing nothing and
exiting non-zero, on two conditions: the resolved bin dir is not
absolute, or it contains a character that cannot be embedded safely in a
quoted rc line. The non-zero exit is load-bearing — `install.sh` only
runs its inline PATH fallback when the CLI fails, so an aborting run
still leaves the user with a working `PATH` instead of a green install
and `command not found`.

**Narrow unsafe-character set.** The bin dir is only ever emitted inside
double quotes (`export PATH="<dir>:$PATH"`, `set --export PATH "<dir>"
$PATH`), where bash and zsh expand only `` ` ``, `$`, `\`, `"` and fish
a subset of those. `;`, `|`, `&`, `(`, `)`, `'` are literal there, so
they no longer abort — `/Users/o'brien/.composio` is a legitimate path.
Newline/carriage return and `:` remain rejected as structural: one
splits the block into extra lines, the other is the PATH separator.

**`install.sh` injection fix.** Because an abort now hands PATH setup to
`install.sh`'s inline fallback, that writer's escaping matters. It
interpolated `COMPOSIO_INSTALL_DIR` raw into the fish and zsh rc lines
and escaped only `"` in the bash arm — so a directory the CLI rejects
was written unescaped into `~/.zshrc` or `config.fish`, where `$(...)`
or a backtick becomes live command substitution at the next shell start.
All three arms now escape backslash, backtick, `$`, and `"` before
embedding, skipping the backtick for fish (which neither substitutes it
nor recognizes `` \` `` inside double quotes). The `$HOME` prefix is
re-applied after escaping, so the intended variable reference survives
while a user-supplied `$` does not.

**CI guard.** `cli.test-installation.yml`'s shell-config check accepted
the legacy `install.sh` block on every leg, justified by a comment
claiming no leg installs a binary built from this checkout. That was
false: `build-cli-binaries.yml` calls the workflow with the tag it just
released, so a completely broken `composio install` silently falling
through to `install.sh`'s writer still reported success. Callers now
declare `built_from_this_checkout`, and those legs must show the
CLI-managed line. `promote-stable` keeps the permissive check because it
rebuilds the promoted beta's own commit, which can predate the writer.

## Known behavior, documented rather than coded around

The rc block no longer records `export COMPOSIO_INSTALL_DIR=`. A user
who installed to a custom directory and later re-runs `curl ... | bash`
without re-specifying the variable gets a second install under
`~/.composio` while their rc `PATH` still resolves the old binary.
Reachability is narrow — existing users are unaffected and `composio
upgrade`, the documented path, replaces `process.execPath` in place and
never consults this. The obvious fix (`command -v composio` + `readlink
-f` inside `install.sh`) can misfire on a foreign `composio`, so this is
a CHANGELOG note telling custom-dir users to re-specify
`COMPOSIO_INSTALL_DIR` or use `composio upgrade`.

## Testing

- `ts/packages/cli/test/src/commands/install.cmd.test.ts` — 47 cases
covering per-shell rendering (full rendered lines, including fish), bash
login-file selection, symlink and mode preservation, legacy-block
migration, idempotency, bin-dir resolution order, and both abort
conditions.
- `test/install-sh-release-resolution.test.sh` — adds a case asserting
that an install directory containing `$(...)` lands in `.bashrc` as
literal text and does not execute when the file is sourced.

Verified locally: `vitest run` for the CLI package (113 files, 1103
passed / 1 skipped), `pnpm run typecheck`, `pnpm run
validate:boundaries`, `pnpm run lint`, `bash -n install.sh`, and `bash
test/install-sh-release-resolution.test.sh`.

## Notes for reviewers

- `@composio/cli` is in `.changeset/config.json`'s ignore list, so this
edits `ts/packages/cli/CHANGELOG.md` directly instead of adding a
changeset.
- No new lint-boundary disables; the two previously registered for this
file (`process.env.SHELL`, `process.env.COMPOSIO_INSTALL_DIR`) are gone,
since both reads now go through `effect/Config`.
- `install.sh` is rewritten wholesale by the follow-up installer PR, so
the change here is the minimum that closes the injection.
- Follow-up #4042 ships a fuller managed-block reconciler with fixtures;
the migration here is its core behavior landed early, without the
fixture harness.
@composio/cli@0.3.2-beta.334 		2026-08-05 16:59:48 +05:30
jkomyno 2024fc4403 Merge remote-tracking branch 'origin/next' into feat/cli-install-shell-flag 2026-08-04 20:19:46 +05:30
Alberto Schiabel 85ce22401d fix(deps): let the hono security bump through the release-age floor (#4057) 
## Why

`next` is red. Dependabot #4051 bumped the `hono` catalog entry to
`^4.12.34`, which pnpm resolved to `4.13.0`. Both that and `4.12.34`
were published inside the 4320-minute (72h) `minimumReleaseAge` floor,
so `pnpm install --frozen-lockfile` rejects the lockfile — on `next`
itself and on every PR branched from it.

```
[ERR_PNPM_MINIMUM_RELEASE_AGE_VIOLATION] 1 lockfile entries failed verification:
  hono@4.13.0 was published at 2026-08-03T21:47:05.000Z, within the minimumReleaseAge cutoff
```

Waiting it out is not neutral, because of which versions sit on which
side of the floor:

| Version | Published | Clears the 72h floor | Has the CORS ReDoS fix |
|---|---|---|---|
| 4.12.33 | 2026-07-31 10:42 | yes | **no** |
| 4.12.34 | 2026-08-03 02:36 | not until Aug 6 02:36 | yes |
| 4.13.0 | 2026-08-03 21:54 | not until Aug 6 21:54 | yes |

The newest version old enough to pass the gate is the one the advisory
flags as vulnerable. So pinning back to a compliant version means
deliberately shipping the vulnerable release for two days.

## What changed

One entry added to `minimumReleaseAgeExclude`, with its removal
condition inline. No lockfile change — `pnpm install --frozen-lockfile`
goes from exit 1 to exit 0 with the lockfile untouched.

## Why this is a safe trade

The floor exists to catch compromised fresh releases. `hono` is only
pulled in by `ts/e2e-tests/runtimes/cloudflare/*` and
`ts/examples/cloudflare-wrangler` — test fixtures and examples. It ships
in no published package, so the blast radius of taking it early is
CI-only, while the advisory it fixes is real.

## Verification

```
pnpm install --frozen-lockfile   # exit 0, pnpm-lock.yaml unmodified
```

## Follow-up

Delete the `hono` entry once the resolved version is past the floor
(after 2026-08-06). The inline comment says so.
 2026-08-04 20:19:08 +05:30
dependabot[bot] 02c7af88ae chore(deps): bump hono from 4.12.31 to 4.12.34 in the npm-security group across 1 directory (#4051) 
Bumps the npm-security group with 1 update in the / directory:
[hono](https://github.com/honojs/hono).

Updates `hono` from 4.12.31 to 4.12.34
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/honojs/hono/releases">hono's
releases</a>.</em></p>
<blockquote>
<h2>v4.12.34</h2>
<h2>Security fixes</h2>
<p>This release includes fixes for the following security issues:</p>
<h3><code>memo()</code> retains SSR output across requests, leading to
cross-user data disclosure</h3>
<p>Affects: <code>hono/jsx</code> (server-side rendering). Fixes
<code>memo()</code> reusing a retained render result across requests
when props compare equal, where a component reading request-scoped
values from ambient context — <code>useContext()</code>,
<code>useRequestContext()</code>, or <code>getContext()</code> — could
serve HTML rendered for another user's request, disclosing account data
or request-scoped secrets such as CSRF tokens. GHSA-f23p-vx2j-j53r</p>
<h3>ReDoS in CORS middleware via
<code>Access-Control-Request-Headers</code></h3>
<p>Affects: <code>hono/cors</code>. Fixes a whitespace-tolerant regular
expression with quadratic backtracking used to parse the
<code>Access-Control-Request-Headers</code> preflight header when
<code>allowHeaders</code> is not configured (the default), where a
single preflight request carrying a long whitespace run could consume
seconds of CPU and stall request processing. GHSA-8j4g-w8fx-2239</p>
<h3>Algorithmic complexity DoS in Language Middleware</h3>
<p>Affects: <code>hono/language</code>. Fixes quadratic string
processing in language-tag normalization, where a crafted language tag
with a large number of hyphen-separated subtags — supplied via a query
parameter, cookie, or <code>Accept-Language</code> header — could cause
excessive CPU consumption and block the event loop.
GHSA-54fx-42gc-7vw4</p>
<h3>Proxy Helper does not remove response headers listed in the
<code>Connection</code> header</h3>
<p>Affects: <code>hono/proxy</code>. Fixes <code>proxy()</code>
forwarding response headers that the origin's <code>Connection</code>
header designates as connection-scoped, where headers intended only for
the immediate peer — per RFC 9110 Section 7.6.1 — could be exposed to
clients, disclosing connection-scoped or internal metadata.
GHSA-79qm-7rj5-m7r9</p>
<hr />
<p>Users who use <code>hono/jsx</code> for server-side rendering,
<code>hono/cors</code>, <code>hono/language</code>, or
<code>hono/proxy</code> are strongly encouraged to upgrade to this
version.</p>
<h2>v4.12.33</h2>
<h2>What's Changed</h2>
<ul>
<li>fix(cookie): relax name validation when parsing Cookie header in <a
href="https://redirect.github.com/honojs/hono/pull/5164">honojs/hono#5164</a></li>
<li>chore: bump <code>@hono/node-server</code> in <a
href="https://redirect.github.com/honojs/hono/pull/5167">honojs/hono#5167</a></li>
<li>fix(jsx): handle useSyncExternalStore subscription and snapshot
changes in <a
href="https://redirect.github.com/honojs/hono/pull/5166">honojs/hono#5166</a></li>
<li>chore: remove undici in favor of global fetch in <a
href="https://redirect.github.com/honojs/hono/pull/5168">honojs/hono#5168</a></li>
</ul>
<p><strong>Full Changelog</strong>: <a
href="https://github.com/honojs/hono/compare/v4.12.32...v4.12.33">https://github.com/honojs/hono/compare/v4.12.32...v4.12.33</a></p>
<h2>v4.12.32</h2>
<h2>What's Changed</h2>
<ul>
<li>ci: enable reports for type &amp; bundle size check in <a
href="https://redirect.github.com/honojs/hono/pull/5148">honojs/hono#5148</a></li>
<li>fix(aws-lambda): add jwt and lambda authorizer types for API Gateway
v2 in <a
href="https://redirect.github.com/honojs/hono/pull/5142">honojs/hono#5142</a></li>
<li>fix(sse): emit empty id field to reset Last-Event-ID in <a
href="https://redirect.github.com/honojs/hono/pull/5138">honojs/hono#5138</a></li>
<li>test(cloudflare-workers): add coverage for onClose, onError, send,
and close in Cloudflare Workers websocket adapter in <a
href="https://redirect.github.com/honojs/hono/pull/5145">honojs/hono#5145</a></li>
<li>fix: use <code>Object.create(null)</code> when parsing query,
headers, and params in <a
href="https://redirect.github.com/honojs/hono/pull/5161">honojs/hono#5161</a></li>
<li>fix(secure-headers): keep CSP callbacks scoped to their header in <a
href="https://redirect.github.com/honojs/hono/pull/5147">honojs/hono#5147</a></li>
</ul>
<p><strong>Full Changelog</strong>: <a
href="https://github.com/honojs/hono/compare/v4.12.31...v4.12.32">https://github.com/honojs/hono/compare/v4.12.31...v4.12.32</a></p>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="https://github.com/honojs/hono/commit/734755ace341607628219ea1dd8ca17f01bf1a5c"><code>734755a</code></a>
4.12.34</li>
<li><a
href="https://github.com/honojs/hono/commit/9839ff32a349bf088b6ddfa604010879dd2d3a05"><code>9839ff3</code></a>
chore: update <code>bun.lock</code> (<a
href="https://redirect.github.com/honojs/hono/issues/5182">#5182</a>)</li>
<li><a
href="https://github.com/honojs/hono/commit/0c45036d6b0ddf42ab2fa44639dc8710825d5c0f"><code>0c45036</code></a>
Merge commit from fork</li>
<li><a
href="https://github.com/honojs/hono/commit/720b566290793d4358bf39843adcb7cf4da4548f"><code>720b566</code></a>
Merge commit from fork</li>
<li><a
href="https://github.com/honojs/hono/commit/f70e2c31684387b3231cc38512a31df6ca76a1c7"><code>f70e2c3</code></a>
Merge commit from fork</li>
<li><a
href="https://github.com/honojs/hono/commit/93fc250d8b4df58ea542cb945171de8013d5e6d5"><code>93fc250</code></a>
Merge commit from fork</li>
<li><a
href="https://github.com/honojs/hono/commit/51db3131d5e97076327edaa0afdb60ebb77c264f"><code>51db313</code></a>
4.12.33</li>
<li><a
href="https://github.com/honojs/hono/commit/aed146364d5c48a8336b8c82fedfabebf8063d07"><code>aed1463</code></a>
chore: remove undici in favor of global fetch (<a
href="https://redirect.github.com/honojs/hono/issues/5168">#5168</a>)</li>
<li><a
href="https://github.com/honojs/hono/commit/224d2f5cbf2b4bc2ebb7482d0592149a8d9f0574"><code>224d2f5</code></a>
fix(jsx): handle useSyncExternalStore subscription and snapshot changes
(<a
href="https://redirect.github.com/honojs/hono/issues/5166">#5166</a>)</li>
<li><a
href="https://github.com/honojs/hono/commit/df653cea0450657977887d56a5188368387456c8"><code>df653ce</code></a>
chore: bump <code>@hono/node-server</code> (<a
href="https://redirect.github.com/honojs/hono/issues/5167">#5167</a>)</li>
<li>Additional commits viewable in <a
href="https://github.com/honojs/hono/compare/v4.12.31...v4.12.34">compare
view</a></li>
</ul>
</details>
<br />


[![Dependabot compatibility
score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=hono&package-manager=npm_and_yarn&previous-version=4.12.31&new-version=4.12.34)](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)

Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.

[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)

---

<details>
<summary>Dependabot commands and options</summary>
<br />

You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore <dependency name> major version` will close this
group update PR and stop Dependabot creating any more for the specific
dependency's major version (unless you unignore this specific
dependency's major version or upgrade to it yourself)
- `@dependabot ignore <dependency name> minor version` will close this
group update PR and stop Dependabot creating any more for the specific
dependency's minor version (unless you unignore this specific
dependency's minor version or upgrade to it yourself)
- `@dependabot ignore <dependency name>` will close this group update PR
and stop Dependabot creating any more for the specific dependency
(unless you unignore this specific dependency or upgrade to it yourself)
- `@dependabot unignore <dependency name>` will remove all of the ignore
conditions of the specified dependency
- `@dependabot unignore <dependency name> <ignore condition>` will
remove the ignore condition of the specified dependency and ignore
conditions
You can disable automated security fix PRs for this repo from the
[Security Alerts
page](https://github.com/ComposioHQ/composio/network/alerts).

</details>

Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
 2026-08-04 19:20:31 +05:30
dependabot[bot] f286ca98ac chore(deps): bump the uv group across 2 directories with 1 update (#4052) 
Bumps the uv group with 1 update in the / directory:
[cryptography](https://github.com/pyca/cryptography).
Bumps the uv group with 1 update in the
/python/providers/claude_agent_sdk directory:
[cryptography](https://github.com/pyca/cryptography).

Updates `cryptography` from 49.0.0 to 50.0.0
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/pyca/cryptography/blob/main/CHANGELOG.rst">cryptography's
changelog</a>.</em></p>
<blockquote>
<p>50.0.0 - 2026-07-31</p>
<pre><code>
* **SECURITY ISSUE**:

:func:`~cryptography.hazmat.primitives.serialization.pkcs7.pkcs7_decrypt_der`
and its PEM and S/MIME variants no longer expose distinguishable errors
or
timing when unwrapping a ``RecipientInfo``'s ``encryptedKey``, which
could
act as a Bleichenbacher oracle for callers that decrypt untrusted
messages.
A random key is now substituted on failure, as described in :rfc:`3218`.
  Credit to **@X1AOxiang** for reporting the issue. **CVE-2026-69247**
* Deprecated Diffie-Hellman key exchange over finite fields (FFDH).
  Everything FFDH is deprecated, including the types in
``cryptography.hazmat.primitives.asymmetric.dh`` and loading FFDH keys
or
  parameters with the key loading APIs. Users should migrate to a more
  modern key exchange algorithm.
* Added ``xof()`` class methods to
  :class:`~cryptography.hazmat.primitives.hashes.SHAKE128` and
:class:`~cryptography.hazmat.primitives.hashes.SHAKE256` for
constructing
  algorithm instances configured for use with
  :class:`~cryptography.hazmat.primitives.hashes.XOFHash`.
* The :mod:`X.509 verification &lt;cryptography.x509.verification&gt;`
APIs are now
  considered stable and are subject to our API stability policy.
* Added the :doc:`/cobblestone` recipe, an implementation of the
  Cobblestone-128 and Cobblestone-256 instantiations of the `C2SP
  chunked-encryption specification
&lt;https://c2sp.org/chunked-encryption&gt;`_ for streaming
authenticated
  encryption of large messages.
* Parsing a Signed Certificate Timestamp list now rejects encodings that
carry trailing bytes after the list or after an individual SCT, instead
of
  silently ignoring them.
* Added support for using :class:`~cryptography.x509.Name` as a field
type in
  the :doc:`/hazmat/asn1/index` module.
* Loading a public key or an EC private key now rejects DER where the
``subjectPublicKey`` (or EC ``publicKey``) ``BIT STRING`` declares a
non-zero
  number of unused bits, instead of silently ignoring it.
* Parsing a CRL entry's ``InvalidityDate`` extension now rejects a
``GeneralizedTime`` that carries fractional seconds or another non-DER
form,
matching the strict encoding already required for every other X.509 time
  field.
* :func:`~cryptography.x509.ocsp.load_der_ocsp_request` and
:func:`~cryptography.x509.ocsp.load_der_ocsp_response` now reject a
request
or response whose ``version`` field is not ``v1``, the only version
defined
by RFC 6960, matching the version validation already performed when
loading
  certificates, CSRs and CRLs.
* :class:`~cryptography.hazmat.primitives.hashes.XOFHash` is now
supported
  when building against AWS-LC.
* HMAC (and therefore PBKDF2-HMAC) with SHA-3 hashes is now supported
when
  building against AWS-LC.
* Diffie-Hellman (:doc:`/hazmat/primitives/asymmetric/dh`) is now
supported
  when building against AWS-LC.
&lt;/tr&gt;&lt;/table&gt; 
</code></pre>
</blockquote>
<p>... (truncated)</p>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="https://github.com/pyca/cryptography/commit/dcb7050b807b00392fa9fe2eac7cb362fcf355cc"><code>dcb7050</code></a>
Prepare for 50.0.0 release (<a
href="https://redirect.github.com/pyca/cryptography/issues/15372">#15372</a>)</li>
<li><a
href="https://github.com/pyca/cryptography/commit/53fccd93413a8d7f07d6d8999681f27b75cffa3f"><code>53fccd9</code></a>
Don't leak how PKCS#7 encryptedKey decryption failed (<a
href="https://redirect.github.com/pyca/cryptography/issues/15369">#15369</a>)</li>
<li><a
href="https://github.com/pyca/cryptography/commit/d472f978470fbefa521b86d98b2ecccbbb4d1dd8"><code>d472f97</code></a>
Add <code>from __future__ import annotations</code> to all src/ Python
files (<a
href="https://redirect.github.com/pyca/cryptography/issues/15371">#15371</a>)</li>
<li><a
href="https://github.com/pyca/cryptography/commit/908773d53829fb1466c6db364b31321c3cd8eb9a"><code>908773d</code></a>
Bump downstream dependencies in CI (<a
href="https://redirect.github.com/pyca/cryptography/issues/15368">#15368</a>)</li>
<li><a
href="https://github.com/pyca/cryptography/commit/2cc07cc948948211899bcb0cddd1fddf86e95812"><code>2cc07cc</code></a>
Bump BoringSSL, OpenSSL, AWS-LC in CI (<a
href="https://redirect.github.com/pyca/cryptography/issues/15367">#15367</a>)</li>
<li><a
href="https://github.com/pyca/cryptography/commit/c94ede9f040fa44942f7139772603419000acf66"><code>c94ede9</code></a>
chore(deps): bump ruff from 0.16.0 to 0.16.1 (<a
href="https://redirect.github.com/pyca/cryptography/issues/15366">#15366</a>)</li>
<li><a
href="https://github.com/pyca/cryptography/commit/67a8308dc9ea4cce6056e0f1438f903c208c3f35"><code>67a8308</code></a>
chore(deps): bump virtualenv from 21.7.0 to 21.7.1 (<a
href="https://redirect.github.com/pyca/cryptography/issues/15365">#15365</a>)</li>
<li><a
href="https://github.com/pyca/cryptography/commit/95018ffcdbbc510fd92fc872e3a3e80aa6e58596"><code>95018ff</code></a>
Release the GIL in one-shot AEAD encrypt/decrypt (<a
href="https://redirect.github.com/pyca/cryptography/issues/15361">#15361</a>)</li>
<li><a
href="https://github.com/pyca/cryptography/commit/6954733eaf55a0074abf88f06f7242dfca3a5d02"><code>6954733</code></a>
Release the GIL during DH and DSA parameter generation (<a
href="https://redirect.github.com/pyca/cryptography/issues/15364">#15364</a>)</li>
<li><a
href="https://github.com/pyca/cryptography/commit/6893b94c33e948f6240082461424cfb5da2dacc6"><code>6893b94</code></a>
Import _serialization instead of serialization in x509/extensions (<a
href="https://redirect.github.com/pyca/cryptography/issues/15363">#15363</a>)</li>
<li>Additional commits viewable in <a
href="https://github.com/pyca/cryptography/compare/49.0.0...50.0.0">compare
view</a></li>
</ul>
</details>
<br />

Updates `cryptography` from 49.0.0 to 50.0.0
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/pyca/cryptography/blob/main/CHANGELOG.rst">cryptography's
changelog</a>.</em></p>
<blockquote>
<p>50.0.0 - 2026-07-31</p>
<pre><code>
* **SECURITY ISSUE**:

:func:`~cryptography.hazmat.primitives.serialization.pkcs7.pkcs7_decrypt_der`
and its PEM and S/MIME variants no longer expose distinguishable errors
or
timing when unwrapping a ``RecipientInfo``'s ``encryptedKey``, which
could
act as a Bleichenbacher oracle for callers that decrypt untrusted
messages.
A random key is now substituted on failure, as described in :rfc:`3218`.
  Credit to **@X1AOxiang** for reporting the issue. **CVE-2026-69247**
* Deprecated Diffie-Hellman key exchange over finite fields (FFDH).
  Everything FFDH is deprecated, including the types in
``cryptography.hazmat.primitives.asymmetric.dh`` and loading FFDH keys
or
  parameters with the key loading APIs. Users should migrate to a more
  modern key exchange algorithm.
* Added ``xof()`` class methods to
  :class:`~cryptography.hazmat.primitives.hashes.SHAKE128` and
:class:`~cryptography.hazmat.primitives.hashes.SHAKE256` for
constructing
  algorithm instances configured for use with
  :class:`~cryptography.hazmat.primitives.hashes.XOFHash`.
* The :mod:`X.509 verification &lt;cryptography.x509.verification&gt;`
APIs are now
  considered stable and are subject to our API stability policy.
* Added the :doc:`/cobblestone` recipe, an implementation of the
  Cobblestone-128 and Cobblestone-256 instantiations of the `C2SP
  chunked-encryption specification
&lt;https://c2sp.org/chunked-encryption&gt;`_ for streaming
authenticated
  encryption of large messages.
* Parsing a Signed Certificate Timestamp list now rejects encodings that
carry trailing bytes after the list or after an individual SCT, instead
of
  silently ignoring them.
* Added support for using :class:`~cryptography.x509.Name` as a field
type in
  the :doc:`/hazmat/asn1/index` module.
* Loading a public key or an EC private key now rejects DER where the
``subjectPublicKey`` (or EC ``publicKey``) ``BIT STRING`` declares a
non-zero
  number of unused bits, instead of silently ignoring it.
* Parsing a CRL entry's ``InvalidityDate`` extension now rejects a
``GeneralizedTime`` that carries fractional seconds or another non-DER
form,
matching the strict encoding already required for every other X.509 time
  field.
* :func:`~cryptography.x509.ocsp.load_der_ocsp_request` and
:func:`~cryptography.x509.ocsp.load_der_ocsp_response` now reject a
request
or response whose ``version`` field is not ``v1``, the only version
defined
by RFC 6960, matching the version validation already performed when
loading
  certificates, CSRs and CRLs.
* :class:`~cryptography.hazmat.primitives.hashes.XOFHash` is now
supported
  when building against AWS-LC.
* HMAC (and therefore PBKDF2-HMAC) with SHA-3 hashes is now supported
when
  building against AWS-LC.
* Diffie-Hellman (:doc:`/hazmat/primitives/asymmetric/dh`) is now
supported
  when building against AWS-LC.
&lt;/tr&gt;&lt;/table&gt; 
</code></pre>
</blockquote>
<p>... (truncated)</p>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="https://github.com/pyca/cryptography/commit/dcb7050b807b00392fa9fe2eac7cb362fcf355cc"><code>dcb7050</code></a>
Prepare for 50.0.0 release (<a
href="https://redirect.github.com/pyca/cryptography/issues/15372">#15372</a>)</li>
<li><a
href="https://github.com/pyca/cryptography/commit/53fccd93413a8d7f07d6d8999681f27b75cffa3f"><code>53fccd9</code></a>
Don't leak how PKCS#7 encryptedKey decryption failed (<a
href="https://redirect.github.com/pyca/cryptography/issues/15369">#15369</a>)</li>
<li><a
href="https://github.com/pyca/cryptography/commit/d472f978470fbefa521b86d98b2ecccbbb4d1dd8"><code>d472f97</code></a>
Add <code>from __future__ import annotations</code> to all src/ Python
files (<a
href="https://redirect.github.com/pyca/cryptography/issues/15371">#15371</a>)</li>
<li><a
href="https://github.com/pyca/cryptography/commit/908773d53829fb1466c6db364b31321c3cd8eb9a"><code>908773d</code></a>
Bump downstream dependencies in CI (<a
href="https://redirect.github.com/pyca/cryptography/issues/15368">#15368</a>)</li>
<li><a
href="https://github.com/pyca/cryptography/commit/2cc07cc948948211899bcb0cddd1fddf86e95812"><code>2cc07cc</code></a>
Bump BoringSSL, OpenSSL, AWS-LC in CI (<a
href="https://redirect.github.com/pyca/cryptography/issues/15367">#15367</a>)</li>
<li><a
href="https://github.com/pyca/cryptography/commit/c94ede9f040fa44942f7139772603419000acf66"><code>c94ede9</code></a>
chore(deps): bump ruff from 0.16.0 to 0.16.1 (<a
href="https://redirect.github.com/pyca/cryptography/issues/15366">#15366</a>)</li>
<li><a
href="https://github.com/pyca/cryptography/commit/67a8308dc9ea4cce6056e0f1438f903c208c3f35"><code>67a8308</code></a>
chore(deps): bump virtualenv from 21.7.0 to 21.7.1 (<a
href="https://redirect.github.com/pyca/cryptography/issues/15365">#15365</a>)</li>
<li><a
href="https://github.com/pyca/cryptography/commit/95018ffcdbbc510fd92fc872e3a3e80aa6e58596"><code>95018ff</code></a>
Release the GIL in one-shot AEAD encrypt/decrypt (<a
href="https://redirect.github.com/pyca/cryptography/issues/15361">#15361</a>)</li>
<li><a
href="https://github.com/pyca/cryptography/commit/6954733eaf55a0074abf88f06f7242dfca3a5d02"><code>6954733</code></a>
Release the GIL during DH and DSA parameter generation (<a
href="https://redirect.github.com/pyca/cryptography/issues/15364">#15364</a>)</li>
<li><a
href="https://github.com/pyca/cryptography/commit/6893b94c33e948f6240082461424cfb5da2dacc6"><code>6893b94</code></a>
Import _serialization instead of serialization in x509/extensions (<a
href="https://redirect.github.com/pyca/cryptography/issues/15363">#15363</a>)</li>
<li>Additional commits viewable in <a
href="https://github.com/pyca/cryptography/compare/49.0.0...50.0.0">compare
view</a></li>
</ul>
</details>
<br />


Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.

[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)

---

<details>
<summary>Dependabot commands and options</summary>
<br />

You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore <dependency name> major version` will close this
group update PR and stop Dependabot creating any more for the specific
dependency's major version (unless you unignore this specific
dependency's major version or upgrade to it yourself)
- `@dependabot ignore <dependency name> minor version` will close this
group update PR and stop Dependabot creating any more for the specific
dependency's minor version (unless you unignore this specific
dependency's minor version or upgrade to it yourself)
- `@dependabot ignore <dependency name>` will close this group update PR
and stop Dependabot creating any more for the specific dependency
(unless you unignore this specific dependency or upgrade to it yourself)
- `@dependabot unignore <dependency name>` will remove all of the ignore
conditions of the specified dependency
- `@dependabot unignore <dependency name> <ignore condition>` will
remove the ignore condition of the specified dependency and ignore
conditions
You can disable automated security fix PRs for this repo from the
[Security Alerts
page](https://github.com/ComposioHQ/composio/network/alerts).

</details>

Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
 2026-08-04 19:20:09 +05:30
jkomyno 16b167c94a docs(cli): document COMPOSIO_BIN_DIR and the install abort contract 
COMPOSIO_BIN_DIR was discoverable only by reading the changelog: it is
read through a raw ConfigProvider and appeared in no help text. Add it to
the README env-var table with its resolution order, and name it in the
install command description so `composio install --help` mentions it.
No --bin-dir flag: the env var is the right shape for an installer
handoff.

The changelog entry also picks up the behavior changes it was missing —
the non-zero exit on abort and what it means for install.sh's fallback,
both abort conditions, the narrowed character set, legacy-block
migration, and a note for custom-install-dir users reinstalling without
re-specifying COMPOSIO_INSTALL_DIR.
 2026-08-04 19:17:14 +05:30
jkomyno d17844c848 ci(cli): fail the installation guard when a freshly built release skips the PATH write 
The shell-config check accepted the legacy install.sh block on every leg,
justified by a comment claiming no leg installs a binary built from this
checkout. Build CLI Binaries calls this workflow with the tag it just
released, so that leg does exercise the new binary — and a completely
broken `composio install` that fell through to install.sh's writer still
reported success.

Callers now declare built_from_this_checkout; those legs must show the
CLI-managed PATH line. promote-stable keeps the permissive check, since
it rebuilds the promoted beta's own commit, which can predate the writer.
 2026-08-04 19:16:23 +05:30
jkomyno 745bd67cef fix(cli): make composio install reconcile stale managed blocks 
Three changes to the PATH writer, all around the same failure mode: the
command reporting success while leaving a shell unable to find composio.

- The unsafe-path denylist rejected characters that are literal inside
  the double quotes the bin dir is always written in. Keep only what
  bash, zsh, and fish still expand there, plus newline and the PATH
  separator, which are structural. /Users/o'brien/.composio now works.
- A file carrying the marker was treated as configured forever, so the
  legacy three-line block written by install.sh's fallback or by an
  older CLI was never migrated. Skip only on the exact rendered PATH
  line for the resolved bin dir; otherwise splice the current block over
  the stale one in place.
- The reachability skip used the invoking process's $PATH as evidence
  about future shells, so an ad-hoc export or a mise/direnv shim made
  the command persist nothing and exit 0. A redundant PATH line is
  harmless, and the content check already prevents duplicates.

installShellIntegration no longer takes an execPath override; it always
reads NodeProcess, and tests thread their exec path through the test
layer instead.
 2026-08-04 19:16:09 +05:30
jkomyno 9f10adcc8d fix(installer): escape the install dir before writing it into shell rc files 
install.sh's inline PATH fallback interpolated COMPOSIO_INSTALL_DIR raw
into the fish and zsh rc lines, and escaped only " in the bash arm. Since
that fallback is exactly what runs when `composio install` rejects a path
and exits non-zero, a directory containing $(...) or a backtick was
written unescaped into ~/.zshrc or config.fish and became live command
substitution at the next shell start.

Escape backslash, backtick, $ and " for every arm before the value is
embedded, skipping the backtick for fish (which neither substitutes it
nor recognizes \` inside double quotes). The $HOME prefix is re-applied
after escaping so the intended variable reference survives while a
user-supplied $ does not.
 2026-08-04 19:15:59 +05:30
Alberto Schiabel 331a1373de Merge branch 'next' into feat/cli-install-shell-flag 2026-08-04 18:25:57 +05:30
Alberto Schiabel f7a4503bbe fix(deps): clear high-severity TypeScript audit findings (#4050) 
This PR:
- follows up on the failed TypeScript audit in
https://github.com/ComposioHQ/composio/pull/4048
- adds patched transitive floors for `fast-uri`, `ip-address`, and
`brace-expansion`
- refreshes `pnpm-lock.yaml` to resolve 3.1.5, 10.4.0, and 5.0.9
respectively
- clears all high-severity findings from `pnpm audit --prod
--audit-level=high`; one low and one moderate advisory remain below the
gate
- verifies the affected CLI dependency graph with a frozen install,
package build, and 1,072 passing tests (1 skipped)
 2026-08-04 17:23:05 +05:30
Alberto Schiabel 15c07ec6c7 docs(cli): restore 0.3.0 and 0.3.1 changelog entries (#4048) 
This PR:
- restores missing `0.3.0` and `0.3.1` sections in
`ts/packages/cli/CHANGELOG.md`
- moves the plugin hint and telemetry changes out of `0.2.33`
- records post-`0.3.1` connected-account and login fixes under
`Unreleased`
- rewrites the restored notes as concise, user-facing bullets
- validates the ignored-package boundary with `pnpm validate:changesets`
@composio/cli@0.3.2-beta.333 		2026-08-04 17:10:43 +05:30
Soumya Medapati 9a51faf574 docs: "latest" requires the skip-version-check flag for manual execution (#4046) 
## What

Runtime testing during eval-rerun prep caught a docs/runtime mismatch:
the guides say `toolkit_versions={"x": "latest"}` works for direct
execution, but `tools.execute()` rejects it —

```
ToolVersionRequiredError: Toolkit version not specified. For manual execution of the
tool please pass a specific toolkit version.
  1. Pass the toolkit version as a parameter to the execute function
     ("latest" is not supported in manual execution)
  ...
  4. Set dangerously_skip_version_check to True
```

Notably, the [TypeScript SDK
reference](/reference/sdk-reference/typescript/tools) already documents
the real behavior — the guides contradicted it. An isolated eval agent
independently hit the same wall and reported it.

Per SDK guidance (@abir-taheer): pass
`dangerously_skip_version_check=True` / `dangerouslySkipVersionCheck:
true` when running `latest` manually.

## Changes

- **All direct-execution samples** (executing-tools,
sessions-vs-direct-execution, custom-auth-params,
before/after-execution-modifiers) keep `"latest"` and add the skip flag
to the execute call with a one-line comment
- **executing-tools warning callout** now presents both paths:
skip-check when an LLM consumes outputs; pinned version (via
`toolkits.get(slug).meta.version`) when code parses them
- **toolkit-versioning page**: the "latest is valid" claims are
corrected to name the manual-execution requirement
- **LLM guardrails** (direct-execution block): same correction — this
block is what AI agents copy verbatim
- **execute-version static test**: now also fails any page showing
`"latest"` in execute samples without the flag (with the runtime
evidence cited in the header comment)

## Verification

- Both patterns executed against the live API before shipping: `latest`
+ flag → success; pinned via `toolkits.get(slug).meta.version` (resolved
`20260615_00`) → success; `latest` alone → the error above
- `bun test tests/static/` — 145 pass; negative check confirmed the new
rule fails with an actionable message when the flag is removed
- `bun run lint:links` — clean

## Note for reviewer

The pinned-version path also returns the *documented* nested response
schema — the "flat response" drift agents reported was a base-version
(`00000000_00`) artifact. Fixing versioning quietly resolves that report
too.

🤖 Generated with [Claude Code](https://claude.com/claude-code)
 2026-08-03 16:31:58 -07:00
Soumya Medapati 52e538286e docs: 'latest' requires dangerously_skip_version_check for manual execution 
Runtime testing during eval-rerun prep caught that toolkit_versions
'latest' is rejected by tools.execute() (ToolVersionRequiredError:
'"latest" is not supported in manual execution') — the guides recommended
it anyway; only the TS SDK reference documented the real behavior.

Per SDK team (Abir): pass dangerously_skip_version_check=True /
dangerouslySkipVersionCheck: true when running 'latest' manually. All
direct-execution samples now include the flag with a one-line comment;
the version-required callout explains both paths (skip-check for
LLM-consumed outputs, pinned via toolkits.get(slug).meta.version for
parsed outputs); the toolkit-versioning page's 'latest' claims are
corrected; the execute-version static test now fails any page showing
'latest' without the flag. Both patterns runtime-verified against the
live API before shipping.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
 2026-08-03 16:23:22 -07:00
shams haroon fee2a73a7e docs: document Custom MCP toolkit logo upload (#4021) 
## Problem

Custom MCP docs don't mention logos, so developers don't know they can
replace the default Composio logo their toolkit shows in the dashboard
and on end-user connect screens.

## What this adds

A new "Add a toolkit logo" section on the Custom MCP page, after
registration: the `toolkit_config.logo_file` field (base64 `content` +
`mime_type`), a cURL example with a placeholder base64 value, the
constraints (PNG/JPEG, square 256-1024px, max 3MB, single-line base64),
the default-logo behavior when omitted, and the insert-only implication
that changing a logo means delete + re-register. Follows the docs
convention of language/OS-neutral examples.

## Testing

`bun run lint` (0 errors) and `bun run lint:links` (0 errors) from
`docs/`.

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

https://claude.ai/code/session_016x2W47caMs6zW4V8uu1M9g
 2026-08-03 16:00:25 -07:00
Soumya Medapati 8dffbcf888 docs: toolkit-discovery entry points + version-policy CI check (eval findings round 2) (#4045) 
## What

Round 2 of fixes from the 97-agent docs eval (findings:
ctx.composio.io/soumya/docs-agent-eval/findings-97-run.md). Follow-up to
#3999.

## Commit 1 — toolkit-discovery entry points (eval finding 3)

51/97 agents struggled to identify the right toolkit; 15 abandoned the
docs for the raw REST API. The catalog and search already exist and
score well (46/97 praised them once found) — these edits wire them into
the paths readers actually take:

- Quickstart intro: "1000+ apps" now links to the /toolkits catalog
- executing-tools + fetching-tools: a "finding a toolkit and tool"
pointer (catalog, `composio search`, semantic search) before the
parameter-finding guidance
- direct-execution LLM guardrails: a discovery rule, so AI readers stop
inventing their own path via the REST API

## Commit 2 — version-policy static test (the durable half of eval
finding 1)

The content fix for the 72/97 `ToolVersionRequiredError` failure landed
in #3999; this keeps it fixed. New
`tests/static/execute-version.test.ts`: any authored page whose code
fences call `tools.execute()` must show version configuration in its
fences; the LLM guardrail blocks are held to the same rule. Changelog,
generated reference, and migration guides are exempt as
historical/point-in-time records.

Running the new rule against current content caught **five more pages**
shipping version-less execute samples that the eval never visited —
including sessions-vs-direct-execution. Fixed in the same commit.

## Verification

- `bun test tests/static/` — 145 pass (including the new test)
- Negative check verified: removing a version token from a page fails
the test with an actionable message naming the file
- `bun run lint:links` — clean

🤖 Generated with [Claude Code](https://claude.com/claude-code)
 2026-08-03 13:55:27 -07:00
Soumya Medapati 70f6772037 docs: enforce toolkit-version policy on execution samples via static test 
Adds tests/static/execute-version.test.ts: any authored page whose code
fences call tools.execute() must show version configuration, and the LLM
guardrail blocks are held to the same rule. Fixes the five pages the
audit caught (sessions-vs-direct-execution, custom-auth-params,
before/after-execution-modifiers) which shipped version-less samples.
Changelog, generated reference, and migration guides are exempt as
historical/point-in-time records.

This is the durable half of eval finding 1: the content fix landed in
#3999; this test keeps future samples from regressing.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
 2026-08-03 12:17:55 -07:00
Soumya Medapati 1857a8fa1c docs: add toolkit-discovery entry points from quickstart and execution pages 
Eval finding 3: 51/97 agents struggled to identify the right toolkit;
15 abandoned the docs for the raw REST API. Links the toolkits catalog
from the quickstart intro, adds a find-your-toolkit pointer to the
executing-tools and fetching-tools pages, and adds a discovery rule to
the direct-execution LLM guardrails.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
 2026-08-03 11:57:27 -07:00
Alberto Schiabel 1503786358 refactor(core): forbid explicit any and type JSON Schema recursively (#3968) 
This PR:

- is refreshed directly onto the current next branch now that #3966 and
#3967 have merged; the PR contains only its intended type-safety work
- enforces no explicit any through the standard .oxlintrc.json, pnpm
lint, and plain oxlint --fix in lint-staged; docs remain covered by
their nested configuration
- replaces the loose JSONSchemaProperty in @composio/core with a
concrete recursive interface, removing explicit any reachable through
Tool.inputParameters and Tool.outputParameters
- includes a minor changeset documenting the type narrowing for
properties, default, and enum consumers
- adds a compile-only public-contract test for recursive schemas,
known-key validation, extension keywords, and Tool reachability
- removes explicit any from FileToolModifier, ts-builders, core and CLI
tests, provider tests, and json-schema-to-zod tests
- keeps TypeScript ESLint-parity rules enabled and closes the
tool-router example lint/typecheck gap
- makes no lockfile changes and no runtime behavior changes

## Context

Final PR from the original #3958 split. The migration foundations are
already on next via #3966 and #3967, so this branch no longer carries a
stacked base commit.
@composio/cli@0.3.2-beta.332 		2026-08-03 22:24:57 +05:30
jkomyno 7198dcce8d docs(cli): explain the bash login-override special case 2026-08-03 21:41:18 +05:30
composio-zen[bot] 8dcc9b9914 docs(sandbox): clarify Composio doesn't run/replace your agent (LLM tokens are sandbox-only & optional) (#3933) 
# Description

Customers evaluating Composio see references to **LLM tokens** and
assume Composio is handing them an agent/LLM that *replaces* their own —
i.e. that they'd be swapping their agent for ours. It isn't: Composio
discovers, authenticates, and executes tools; it never proxies the
customer's model or runs an agent on their behalf.

The one place Composio itself calls a model is **inside the sandbox**
(the optional `invoke_llm` helper + AI-assisted conveniences like error
correction). The sandbox is opt-in per session (`sandbox: { enable: true
}`), so this LLM usage is entirely optional and can be disabled.

This PR adds a short callout to the **Remote sandbox** docs page
(`docs/content/docs/sandbox/remote.mdx`) that says exactly that — placed
right where `invoke_llm` and the sandbox are introduced, with anchor
links to the `invoke_llm` helper, error correction, and session
configuration. It kills the "are they replacing my agent?" misconception
at its source.

The copy is deliberately accurate to today's state: it does **not**
claim we bill LLM tokens (sandbox billing is still upcoming and the
public pricing page only lists Tool Calls). It frames the point
conceptually — *your agent stays yours; the only Composio-side LLM usage
is optional and sandbox-scoped.*

**Follow-up surfaces (not in this PR — see below):** this same
clarification could be mirrored on the dashboard usage/billing UI and
the marketing pricing page when an "LLM tokens" line item actually
surfaces there. Those live outside this repo.

# How did I test this PR

- Docs-only change (single `.mdx` file); no code or dependency surface.
- Verified all anchor targets referenced in the new callout exist on the
same page / site:
  - `#built-in-helpers` → `### Built-in helpers` (the `invoke_llm` row)
  - `#error-correction` → `### Error correction`
- `/docs/configuring-sessions` (existing page; documents `sandbox: {
enable: true }`)
- Matches the existing `<Callout title="...">` component usage already
on the page (the "Renamed from workbench" callout), so it renders
consistently in Fumadocs.
- Confirmed against source that `invoke_llm` (docs `Built-in helpers`
table) is the Composio-side LLM entry point and that the sandbox is
opt-in via the `sandbox`/`workbench` session key.

# Security

- **Scope:** documentation-only change — one `.mdx` file, no
dependencies, lockfiles, or executable code added/changed.
- **Socket / Grype:** not applicable to this diff (no package manifests
or code paths introduced); no new fixable CRITICAL/HIGH/MEDIUM findings
possible from a Markdown copy addition.

Triggered by: palash@composio.dev | Source: slack
Session: https://zen.corp.composio.io/dashboard/#/chat/zen-f6a81a5a6764

---------

Co-authored-by: Zen Agent <zen@composio.dev>
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
 2026-08-03 20:46:56 +05:30
sdkrelease[bot] 082ba79ced docs: update toolkits, API spec, and meta tools data (#3959) 
## Summary
Automated sync of backend data into the docs site. Triggered by:
`schedule`.

## What changed
- **Toolkit catalog** (`docs/public/data/toolkits.json`,
`toolkits-list.json`) — refreshed list of available toolkits, auth
schemes, and tools from the backend API
- **OpenAPI specs** (`docs/public/openapi.json`,
`docs/public/openapi-v3.json`, `docs/public/openapi-webhooks.json`) —
latest v3.1 and v3.0 API specifications plus the webhook-events spec,
fetched from production
- **API reference pages** (`docs/content/reference/api-reference/`,
`docs/content/reference/v3/api-reference/`) — regenerated index pages
for both API versions
- **Meta tools reference** (`docs/public/data/meta-tools.json`,
`docs/content/toolkits/meta-tools/*.mdx`) — updated meta tool schemas
and reference docs

Co-authored-by: Sushmithamallesh <19796925+Sushmithamallesh@users.noreply.github.com>
 2026-08-03 20:46:20 +05:30
jkomyno 648e95727a fix(cli): exit non-zero when shell setup aborts 
Both abort branches (unsafe or relative resolved bin dir) printed an error
and returned, so the effect succeeded and the process exited 0. install.sh
gates its inline PATH fallback on a non-zero exit from 'composio install',
so an aborted setup looked green and left the user with no PATH setup at
all. Raise a typed ShellSetupAbortError after printing the abort reason;
cli-main.ts maps it to exit code 1 without printing anything further, so
install.sh now takes its fallback branch.
 2026-08-03 20:29:52 +05:30
jkomyno 48f3ebe2a1 refactor(cli): type the install test helper's shell param with the Shell union 
The helper widened shell to string and cast it back to the union, bypassing
the checker. Export Shell from install.cmd.ts and use it directly.
 2026-08-03 20:26:09 +05:30
jkomyno 021125b7a8 fix(cli): create the rc tmp copy with the preserved file mode 
The tmp copy was written with the default 0644 mode and only chmod'd to the
target's mode afterwards, so a 0600 private rc's contents sat world-readable
in <target>.composio-tmp for the duration of the window. Create the tmp file
with the preserved mode from the start; open(2) masks that mode with the
umask (only ever clearing bits), so the follow-up chmod stays to pin the
exact mode before the rename.
 2026-08-03 20:25:37 +05:30
jkomyno 5d007da225 fix(ci): accept the legacy PATH block when verifying installed shell config 
The shell-config assertions only passed for binaries that write the new
CLI-managed PATH line, but every leg of this workflow installs a published
release binary: workflow_dispatch re-verification of existing releases,
workflow_call with the default 'latest', and promote-stable rebuilds of an
older beta all install pre-change binaries that write the legacy
COMPOSIO_INSTALL_DIR block (as does install.sh's own fallback). Accept
either working PATH layout, fail only when neither is present, and keep
rejecting a mixed state where the new PATH line coexists with a persisted
COMPOSIO_INSTALL_DIR.
 2026-08-03 20:24:07 +05:30
jkomyno 6d0e14f155 fix(cli): only prefer ~/.local/bin when its composio entry is this executable 
A bare exists-check let any leftover ~/.local/bin/composio (e.g. a pip or
pipx install) win bin-dir resolution, so the PATH line pointed shells at a
foreign program while the installer reported success. Prefer ~/.local/bin
only when its entry realpath-resolves, following symlinks, to the running
executable; otherwise fall through to the runtime executable's directory.
The COMPOSIO_BIN_DIR override stays highest precedence.
 2026-08-03 20:23:14 +05:30
Alberto Schiabel 61aafbc9d3 refactor(docs): parse untyped data with zod and forbid explicit any (#3967) 
This PR:

- builds on top of https://github.com/ComposioHQ/composio/pull/3966
- enables `typescript/no-explicit-any` (error, `fixToUnknown`) for docs
in `docs/.oxlintrc.json` and removes every remaining explicit `any` in
docs code
- parses untyped/external data once at the boundary with zod v4 schemas
and lets `z.infer` types flow downstream — no hand-rolled `'x' in obj`
guard chains, no `as`-casts of untyped page data, no
`docs/lib/unknown-value.ts`
- adds domain schema modules: `docs/lib/toolkit-schema.ts` (recursive
JSON-Schema node, raw tool/trigger payloads, list envelopes) and
`docs/lib/reference-page-data.ts` (fumadocs reference page data for both
reference routes)
- rewrites `validate-links.ts`, `generate-toolkits.ts`,
`generate-meta-tools.ts`, the `llms.mdx` route, and
`deprecated-api-sidebar.tsx` on those schemas with identical validation
outcomes
- carries the pure typing improvements from the earlier attempt (typed
reference source in `source.ts`, `LLMPage`/`PageLike`, typed
`ClientLogo[]` in `logo-bar.tsx`, component `any` removals)
- adds `tests/static/toolkit-schema.test.ts` and
`tests/static/generate-toolkits.test.ts` pinning the transform shapes;
no changeset (docs is not published)

## Context

Second of the three-PR split of #3958, replacing its rejected
structural-guard approach with zod schemas at the data boundaries.
Verified with `bun run lint`, `bun run types:check`, `bun test
tests/static/` (125 pass), `bun run lint:links`, and a full `next
build`.

## Review follow-up

Addressed the regressions reported in [the Zod boundary
re-review](https://github.com/ComposioHQ/composio/pull/3967#issuecomment-5105279224):
scalar JSON Schema enums and auth defaults are preserved as strings,
malformed toolkit page envelopes abort generation, and the pre-refactor
empty-string fallbacks are restored. Regression coverage lives in
`tests/static/toolkit-schema.test.ts` and
`tests/static/generate-toolkits.test.ts`.

Verified on `2f26c40be` with `bun test tests/static/` (125 pass), `bun
run types:check`, and `bun run lint` (0 errors; existing warnings only).
 2026-08-03 19:52:04 +05:30
Alberto Schiabel 10e93add6b fix(cli): address bugbot review findings from the guardrails stack (#3886) 
Follow-up to https://github.com/ComposioHQ/composio/pull/3885, which is
now merged into `next`.

This PR:
- reports pending-login cache read failures as I/O errors instead of
masking them as decode failures (`composio login --poll`)
- restores pairwise polarity assertions for the `semverComparator`
Array.sort compatibility case
- consolidates the duplicated ephemeral HTTP server test helper in
`test/__utils__/http-server.ts`
- makes server-owned connected-account statuses forward-compatible while
preserving the credential-stripping schema allowlist
- redacts raw payload values from connected-account parse warnings and
adds regression coverage for unknown statuses and secret-bearing
malformed payloads
- documents why the client-singleton test re-derives the consumer cache
cwd hash

## Rebase notes

Rebased onto `origin/next` at `ef1ec9148`.

- Dropped the empty `GITHUB_*` compatibility commit; that contract is
already present on `next` through
https://github.com/ComposioHQ/composio/pull/3880.
- Adapted the connected-account decoder rename to the service extracted
upstream in `connected-account-selection.ts`.

## Context

Fix-forward PR for actionable Cursor Bugbot findings on the guardrails
stack (#3877–#3885). The stale decode-error string match and unused
release helper were already resolved upstream, and the `vi.stubEnv(...,
undefined)` concern is not actionable on Vitest 4.1.10.
@composio/cli@0.3.2-beta.331 		2026-08-03 19:20:45 +05:30
Rajarshi Datta ef1ec91486 fix(core): name @composio/core in the upgrade notice instead of the v2 composio-core package (#4031) 
Fixes #4030

## Problem

`checkForLatestVersionFromNPM` queried the right package but named the
wrong one in the notice it printed:

```ts
// ts/packages/core/src/utils/version.ts:29
const packageName = '@composio/core';
...
// ts/packages/core/src/utils/version.ts:52
`🚀 Upgrade available! Your composio-core version (${currentVersionFromPackageJson}) is behind. …`
```

`composio-core` is the v2 npm package. A v3 user saw a notice naming a
package they had not installed, and the obvious next step — `npm i
composio-core@latest` — installs the legacy package. That is a downgrade
path, not just a wording slip.

Leftover string from the v2 SDK: the surrounding code was migrated to
`@composio/core`, the message was not.

## Fix

One line — interpolate the constant already in scope, as the issue
suggested:

```diff
-`🚀 Upgrade available! Your composio-core version (${currentVersionFromPackageJson}) is behind. …`
+`🚀 Upgrade available! Your ${packageName} version (${currentVersionFromPackageJson}) is behind. …`
```

I used the constant rather than hardcoding `@composio/core` so the
notice and the registry URL now derive from a single source and cannot
drift apart again.

## Verification

Ran the issue's reproduction against the fix, with the registry response
stubbed and `CI`/`DEVELOPMENT` unset:

```text
🚀 Upgrade available! Your @composio/core version (0.14.1) is behind. Latest version: 0.99.0.
registry URL actually queried: https://registry.npmjs.org/@composio/core/latest
```

The name in the message and the package actually queried now match
exactly.

| Check | Result |
|---|---|
| `tsc --noEmit` | exit 0 |
| Full core suite | 1037 passed / 3 failed — identical to unmodified
`next` |

The 3 failures are pre-existing and environmental on the Windows machine
used here: two `EPERM: symlink` (needs Developer Mode) and one POSIX
path-separator assumption in `fileUtils.test.ts`. Confirmed by stashing
and re-running against `next`.

## Notes

- No test added. Interpolating the constant makes this class of drift
structurally impossible, which is a stronger guarantee than asserting
exact log text. There is also a practical cost: #4026's branch
introduces `ts/packages/core/test/utils/version.test.ts`, so adding that
same new file here would create an add/add conflict between two open
PRs. Happy to add coverage as a follow-up once that one lands.
- Related, deliberately left out of scope.
`ts/packages/cli/src/effects/find-composio-core-generated.ts:38` has the
same stale name, and arguably worse:

```ts
const fix = `Install \`composio-core\` with \`${installCmd} composio-core\`, …`;
```

- The code twelve lines below probes `import composio` — the v3 Python
package — so a user following that message runs `uv pip install
composio-core`, installs v2, and the check still fails. I left it alone
because `@composio/cli` is a separate package with its own release
process (it is excluded from changesets), and the two are independent
string literals with no shared function, so there is no single root to
fix. Worth its own issue.
- I checked the other `composio-core` references repo-wide: the
changelog entries and `docs/content/docs/migration-guide/new-sdk.mdx`
correctly cite v2 as history, and the remainder are CLI test-fixture
directory names. Nothing else needed changing.
 2026-08-03 16:43:01 +05:30
Rajarshi Datta 677508f17b docs(core): correct getToolkitVersionsFromEnv precedence in JSDoc (#4033) 
Fixes #4032

## Problem

The JSDoc on `getToolkitVersionsFromEnv` documented a precedence order
the function does not implement:

```ts
// ts/packages/core/src/utils/sdk.ts:65-69
 * 2. Environment variables (COMPOSIO_TOOLKIT_VERSION_<TOOLKIT_NAME>)
 * 3. User-provided toolkit version mappings (defaultVersions object)
```

The implementation spreads user-provided values last, so they win:

```ts
const toolkitVersions = {
  ...toolkitVersionsFromEnv,
  ...userProvidedToolkitVersions,
};
```

Three independent sources already agreed the code is right and the JSDoc
was the outlier:

1. The inline comment two lines above the spread — "user provided values
act as overrides" (`sdk.ts:91`).
2. `test/core/versions.test.ts:150` (`'should prioritize user-provided
versions over environment variables'`) and `:395` (`'should demonstrate
priority order: user object > env vars > fallback'`).
3. The Python SDK's docstring for the equivalent `get_toolkit_versions`,
which had the order correct.

This misleads anyone debugging a version pin: someone whose
`COMPOSIO_TOOLKIT_VERSION_GITHUB` appears to be ignored reads this and
concludes the env-var handling is broken, when the real cause is their
own `toolkitVersions` object overriding it.

## Fix

Swapped the two lines. Comment-only — no runtime behaviour changes.

```diff
- * 2. Environment variables (COMPOSIO_TOOLKIT_VERSION_<TOOLKIT_NAME>)
- * 3. User-provided toolkit version mappings (defaultVersions object)
+ * 2. User-provided toolkit version mappings (defaultVersions object)
+ * 3. Environment variables (COMPOSIO_TOOLKIT_VERSION_<TOOLKIT_NAME>)
```

I kept this to a pure swap rather than also rewording. The Python
docstring is the parity target, and the two lists are now item-for-item
identical:

1. If `defaultVersions` is a string, use it as global version for all
toolkits
2. User-provided toolkit version mappings (`defaultVersions` object)
3. Environment variables (`COMPOSIO_TOOLKIT_VERSION_<TOOLKIT_NAME>`)
4. Fallback to `'latest'` if no versions are configured

Adding clarifying prose on the TypeScript side alone would have traded
one cross-SDK drift for another.

## Verification

Exercised all four documented items against real behaviour, not just the
one in the report:

```text
env   : COMPOSIO_TOOLKIT_VERSION_GITHUB=from_env_20250101_00, _SLACK=slack_from_env
user  : { github: "from_user_20260101_00" }
result: { github: 'from_user_20260101_00', slack: 'slack_from_env' }

github winner : from_user_20260101_00   <- user-provided (doc item 2)
slack  winner : slack_from_env          <- env var, untouched by user (doc item 3)
string form   : 20260101_00             <- doc item 1
empty form    : latest                  <- doc item 4
```

The slack case is the one worth noting: items 2 and 3 are not a strict
either/or fallback — the two maps merge per toolkit, and env vars still
apply for toolkits the user's object does not mention. The numbered list
describes that correctly now, since what it orders is precedence.

| Check | Result |
|---|---|
| `tsc --noEmit` | exit 0 |
| `test/core/versions.test.ts` | 32 passed |

I ran the targeted suite rather than the full one: the change is a
comment and cannot affect anything outside this file, and those 32 tests
are exactly the ones asserting this precedence.

## Notes

- No changeset — comments only, nothing in the published output changes.
- No test added: the existing tests at `versions.test.ts:150` and `:395`
already lock this behaviour in. They are what proved the code was
correct and the doc was wrong, so the doc is now covered by them too.
 2026-08-03 16:39:40 +05:30
Alberto Schiabel 51056129ee fix(core): detect filesystem case sensitivity for uploads (#4036) 
This PR:
- fixes #4024
- supersedes #4025 with target-filesystem detection instead of
unconditional case folding
- uses `is-fs-case-sensitive` on the nearest existing directory so mixed
mounts and case-sensitive filesystem configurations are handled
correctly
- preserves exact matching on case-sensitive filesystems and falls back
to conservative case-insensitive matching when detection fails
- keeps Node-only detection behind `#platform` and mirrors its runtime
dependency in `@composio/slim`, preserving the workerd-safe bundle and
Slim import
- adds focused Node, workerd, and matcher regressions plus an
`@composio/core` patch changeset
- verifies 1,044 core tests, five CLI upload tests, the Slim
build/import smoke, typecheck, build, ATTW, publint, lint, formatting,
frozen install, and changeset validation
 2026-08-03 16:32:40 +05:30
Alberto Schiabel 03291bfaa4 fix(ci): use locked Node version for Cloudflare E2E (#4035) 
This PR:
- supersedes https://github.com/ComposioHQ/composio/pull/4010 and
credits @MGPOCKY for identifying the stale Cloudflare E2E Node override
- lets Cloudflare E2E resolve the exact Node.js version from mise.lock
through the shared setup action
- retains the release job's explicit Node.js 24.17.0 publishing pin and
corrects its outdated explanation
- verifies the release workflow guard, workflow YAML parsing,
formatting, and whitespace checks

Co-authored-by: MGPOCKY <kkm1447@naver.com>
 2026-08-03 15:45:24 +05:30
palash-c 46e79aa579 docs: use support@composio.dev on Composio Connect (#3985) 
The **I still need help** section of Composio Connect points users at
`tech@composio.dev`.

It's the only place in the docs that does. Every other reference uses
`support@composio.dev`:

- `docs/content/reference/errors.mdx`
- `docs/content/reference/v3/errors.mdx`
- `docs/content/changelog/12-30-25.mdx`
- `docs/content/changelog/01-29-26-sdk-major-update.mdx`
- `docs/content/changelog/03-25-26-mcp-endpoint-removed.mdx`

Composio Connect is the page consumer users land on when wiring up an
MCP client, so this was the most visible instance of the wrong address.

One line changed.

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

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Co-authored-by: Alberto Schiabel <jkomyno@users.noreply.github.com>
 2026-08-03 15:05:58 +05:30
shams haroon dcb03e8898 docs: keep logo example OS-neutral 
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016x2W47caMs6zW4V8uu1M9g
 2026-08-02 19:10:41 -07:00
shams haroon 82d39da58e docs: document Custom MCP toolkit logo upload 
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016x2W47caMs6zW4V8uu1M9g
 2026-08-02 19:02:47 -07:00
shams haroon 0b9f64a53f docs: document is_enabled_for_tool_router on the Custom MCP page (#4019) 
Adds the missing auth-config step to the existing Custom MCP page
(extending-sessions/custom-mcp.mdx): create the config with
`is_enabled_for_tool_router: true`, PATCH guidance for existing configs,
and updates the session + known-gaps sections from "don't rely on
auto-match" to "auto-match works when the flag is set".

Why: session account-matching only considers flagged auth configs, and
after the revert of platform#11223 there is no server-side default for
custom toolkits. A config created without the flag makes every session
execution fail with `NoActiveConnection`. The docs are what stands
between a pilot partner and that dead end.

Draft while the feature is experimental/LD-gated.

🤖 Generated with [Claude Code](https://claude.com/claude-code)
 2026-08-02 16:28:40 -07:00
shams haroon 7a4eb320e1 docs: document is_enabled_for_tool_router on the Custom MCP page 
Session auto-match only considers auth configs with this flag, and the
custom flow has no default (platform#11223 was reverted), so configs
created without it fail session execution with NoActiveConnection. Adds
the auth-config creation step with the flag, a PATCH note for existing
configs, and updates the session and known-gaps guidance from "don't
rely on auto-match" to "auto-match works when the flag is set".

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
 2026-08-02 15:30:20 -07:00
shams haroon 2ada960e06 docs: custom toolkits guide (register, auth config flag, sync, sessions) 
The is_enabled_for_tool_router step is load-bearing: after the revert of
platform#11223 there is no default, and configs created without the flag
make session execution fail with NoActiveConnection.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
 2026-08-02 14:57:14 -07:00
jkomyno 40f6b8b54e feat(cli): add explicit shell setup to install 2026-07-31 18:54:15 +05:30
Anshu Garg 8720957fb2 docs(auth): OAuth connection security in the connected-accounts reference (#3992) 
Documents OAuth connection security (same-browser binding + callback
identity verification) as a section in the **connected-accounts API
reference**, next to the `complete_auth` endpoint it describes, rather
than a standalone `/docs` page.

Written in the connected-accounts overview's own house style (prose
sections, backticks, one warning callout, no em-dashes), carrying the
code-verified facts.

## What's here
- New **OAuth connection security** section in
`api-overviews/connected-accounts.mdx`, mirrored into both generated
`index.mdx` files (v3.1 + v3).
- Changelog entry, links pointed at
`/reference/api-reference/connected-accounts#...`.
- Agent concept map repointed, and a stale claim fixed: callback
identity verification is opt-in per project and covers every connection
once set, not custom-auth-config-only.

## Notes
- No standalone docs page or nav entry (an earlier revision of this
branch had one; removed).
- The `index.mdx` files are normally emitted by `generate:api-index`;
its deps don't resolve in my worktree, so I mirrored the section
manually. It matches what the generator would produce from the updated
overview, but a local regen on a full checkout is worth doing before
merge.
- The dashboard "Learn more" link (#1187) is repointed to this section.

The earlier standalone-page version lives in #3987 (left open and
untouched for comparison).
 2026-07-31 14:25:12 +05:30
Anshu Garg 29af2cdbeb docs(auth): note the create-time callback_url is unused with a verifier URL 
When a verifier URL is set, the OAuth handoff carries only session_uri and the
developer's endpoint owns the final redirect, so a callback_url passed at
connection creation is not used. One clause in the reference; regenerated both
index pages.
 2026-07-31 14:22:18 +05:30
Anshu Garg a4a4427c68 docs(auth): drop same-browser binding from the reference; keep session fixation 
Same-browser binding is not enabled, so remove it from the connected-accounts
reference and concept map. Keep the OAuth session fixation definition as the
rationale for callback identity verification, which is now the single control
the section documents. Regenerated both index pages; repointed the concept map
to #callback-identity-verification.
 2026-07-31 13:56:23 +05:30
Anshu Garg 86c4adf4ab docs(changelog): announce callback identity verification only 
Drop same-browser binding and the session-fixation description from the
changelog. It now announces just the opt-in callback identity verification
feature, framed as a capability, with no attack detail.
 2026-07-31 13:51:46 +05:30
Soumya Medapati f1c1aa5613 docs: make toolkit-version requirement explicit in direct-execution samples (#3999) 
## What

Content fixes to the tool-execution docs, driven by a 97-agent docs eval
(findings: ctx.composio.io/soumya/docs-agent-eval/findings-97-run.md).
72/97 agents following the executing-tools page hit
`ToolVersionRequiredError` because the samples either omit versions
entirely or pin a GitHub-only mapping that doesn't transfer to any other
toolkit.

## Changes

**`docs/content/docs/tools-direct/executing-tools.mdx`**
1. Add an explicit callout in Direct Tool Execution: a toolkit version
is **required**, the error you get without one, the three ways to set
it, and a link to the version-lookup section. (Previously the page only
implied this via one sample's constructor; the "required" rule lived on
a separate page.)
2. Replace the hardcoded `{"github": "20251027_00"}` pin with `"latest"`
plus a comment showing how to find versions
(`composio.toolkits.get(slug).meta.available_versions`) — the old sample
only worked for GitHub and taught a stale pin.
3. Add `toolkit_versions` / `toolkitVersions` to every file-handling
sample (upload, download, Gmail attachment, manual staging, upload-hook)
— all previously threw `ToolVersionRequiredError` when copied.
4. Remove `dangerouslySkipVersionCheck: true` from the upload-hook
sample — it was working around the missing version; samples shouldn't
model the dangerous flag.

**`docs/lib/llm-guardrails/direct-execution.ts`**
5. The LLM-facing guardrails block appended to direct-execution pages
showed a version-less `tools.execute()` sample and a "signature rule"
omitting `version` — the exact pattern that produced the eval's top
failure. Samples and rules now state the requirement.

**`docs/content/docs/quickstart.mdx`**
6. State the Python 3.10+ requirement at the install step, naming the
cryptic `typing.TypeAlias` failure older versions produce (matches
`python/pyproject.toml` `requires-python = ">=3.10,<4"`).

## Verification

All sample signatures checked against the installed SDK (composio 0.18.0
/ composio_client 1.42.0): per-call `version=`, constructor
`toolkit_versions=`, lookup via `toolkits.get(slug).meta.version` /
`.meta.available_versions`. Eval evidence: 72/97 independent agent runs
reproduced the error; per-run logs available.

## Raised for docs-team decision (deliberately NOT changed here)

- **The session guardrails block**
(`docs/lib/llm-guardrails/session.ts`, "CRITICAL INSTRUCTIONS FOR AI
MODELS", appended to most pages): capable eval agents flagged it as
prompt injection (verbatim: "a prompt injection I had to identify and
ignore") and its framing contradicts the sessions-vs-direct-execution
page. Deliberate design, so untouched — recommend reconciling (both
paths legitimate, state when each applies) and softening ALWAYS/NEVER
framing.
- **`legacy: true` on executing-tools + toolkit-versioning**: these are
the canonical link targets for direct execution, but the legacy flag
stamps the LLM view with "may describe outdated APIs" and suppresses
guardrails — eroding agent trust in the current canonical page. Either
promote the pages or point canonical links elsewhere.
- **REST vs SDK naming**: REST query param is `toolkit_versions`, SDK
per-call param is `version` — a recurring source of agent confusion
(eval Finding 4); worth aligning or calling out in the reference.

🤖 Generated with [Claude Code](https://claude.com/claude-code)
 2026-07-30 16:17:38 -07:00
Kshitij Jhunjhunwala 98b7fcee27 feat(cli): agent-aware plugin acquisition hint (PRDE-1153) (#3981) 
## Summary

[PRDE-1153](https://linear.app/composio/issue/PRDE-1153) adds a small
acquisition hint when the bare CLI is running inside Claude Code or
Codex and the Composio plugin is not installed in that host:

```text
Tip: running under Claude Code without the Composio plugin — 'composio setup' installs it.
```

The hint is written only to stderr, including in non-TTY shells, because
agent tool calls commonly capture stderr. It never changes stdout or
command results.

## When the hint appears

All of the following must be true:

- The CLI detects Claude Code via `CLAUDECODE`, or Codex via
`CODEX_THREAD_ID` / `CODEX_SANDBOX`.
- The host's plugin state confidently shows that `composio@composio` is
absent.
- A hint has not been shown for that host within the last 24 hours.
- The current command is not `composio setup`, including when root flags
precede the command.
- The invocation is not a child of `composio run`.

Unreadable or unrecognized plugin state suppresses the hint rather than
risking a false positive.

## Host state and throttling

- Claude Code presence is read from
`~/.claude/plugins/installed_plugins.json`.
- Codex presence is read from `~/.codex/config.toml`.
- `CLAUDE_CONFIG_DIR` and `CODEX_HOME` overrides are honored; blank
overrides fall back to the standard paths.
- Per-host throttle stamps live under `<COMPOSIO_CACHE_DIR or
~/.composio>/plugin-hints/`.

The throttle is best-effort rather than a correctness boundary. Two
processes racing exactly as a stale stamp is replaced may both print the
same tip; the only consequence is a duplicate advisory line.

## Implementation notes

- Detection and presence checks use local environment variables and
small local files only—there is no network request or background worker.
- Shared agent-host names, labels, and the plugin ID are centralized in
`agent-host.ts` and reused by the existing setup flow.
- This PR covers plugin acquisition only. Plugin freshness and CLI
update messaging remain separate concerns.

## Verification

- `plugin-hint.test.ts`: 15 passing tests covering host detection,
plugin presence, suppression rules, per-host throttling, custom/blank
host paths, root flags, concurrency, and non-TTY stderr.
- CLI source typecheck: passed.
- CLI test typecheck: passed.
- Changed-file oxlint and `git diff --check`: passed.
@composio/cli@0.3.1 @composio/cli@0.3.1-beta.329 		2026-07-30 15:58:40 -07:00
Soumya Medapati 88d9cf4033 docs: trim Python version note to the requirement only (review feedback) 
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
 2026-07-30 15:57:52 -07:00
Kshitij Jhunjhunwala faaed16fa9 fix(cli): ignore blank plugin host paths 2026-07-30 11:42:22 -07:00