docs: update guides for SDK changes

[sdkrelease]

Summary

Automated docs update triggered by SDK source changes on next.

• Claude reviewed the SDK diff and updated guides, FAQs, or examples
  that reference changed APIs or features.
• The docs @composio/* dependencies were realigned to their latest
  published releases so Twoslash snippets and example apps validate
  against versions users can actually install.

Review checklist

• Changes accurately reflect the new SDK behavior
• No unrelated docs were modified
• Code examples are correct and complete
• If a documented feature is not published yet, the Twoslash build
  will fail — wait for the release instead of working around it

Generated by Claude Code via GitHub Actions.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
docs	Ready	Preview	Sep 3, 2026 10:31am UTC

[claude]

Claude finished @sdkrelease[bot]'s task in 1m 53s —— View job

---

Docs review — Looks good

• Read docs/agent-guidance/agents/docs-reviewer.md
• Run git diff origin/next...HEAD
• Verify the version claim in the changed callout
• Post review

The PR changes one sentence in docs/content/docs/tools-direct/executing-tools.mdx:499, replacing the vague "a composio release newer than 0.20.0 (Python)" with a concrete "composio 0.21.0 or later (Python)". I verified the claim rather than taking it at face value:

The version is correct. I pulled the published composio 0.20.0 wheel from PyPI and checked the implementation:

# composio 0.20.0 (published) — utils/sensitive_file_upload_paths.py
def _normalize_path_segments(file_path: t.Union[str, Path]) -> t.List[str]:
    p = Path(file_path).expanduser()
    resolved = p.resolve()   # only the resolved path is ever checked

versus the tree on this branch, where python/composio/__version__.py is 0.21.0 and the same helper returns both forms:

# 0.21.0 — python/composio/utils/sensitive_file_upload_paths.py:36
def _normalize_path_segments(file_path) -> tuple[list[str], list[str]]:
    """Return resolved and written segments so neither can hide a denied name."""

So 0.21.0 is genuinely the first Python release with dual-path matching, and "Earlier versions check only the symlink-resolved path" is accurate for 0.20.0 and below.

The unchanged TypeScript half still holds. @composio/core is published at 0.17.0, and .changeset/block-symlinked-sensitive-paths.md marks the symlink fix as a patch — so it lands in 0.17.1, matching what the callout already said. No stale half left behind.

No API-usage, missing-step, or ordering issues; the page is existing content, so no index or meta.json entry is needed.

---

One non-blocking note, since it applies to both halves of the sentence and not to this diff specifically: neither version is published yet (PyPI latest is composio 0.20.0, npm latest is @composio/core 0.17.0). That's expected for docs landing on next alongside a prepared release, but if the docs site can deploy ahead of the release, readers would briefly see a version floor they can't install. Worth confirming the docs deploy is gated on the release going out — no change requested here.
· docs/auto-sdk-sync

[claude]

Claude finished @sdkrelease[bot]'s task in 2m 43s —— View job

---

Docs review — one suggested fix

• Read docs/agent-guidance/agents/docs-reviewer.md
• Run git diff origin/next...HEAD
• Verify the callout's behavioral claims against both SDKs
• Verify the dependency realignment against npm
• Post review

The force-push replaced the earlier one-line version edit with a new callout. Current diff: a 100 MiB download-cap callout in docs/content/docs/tools-direct/executing-tools.mdx:494, plus the ten @composio/* bumps in docs/package.json and the matching docs/bun.lock.

Every behavioral claim in the callout checks out. I read the implementation rather than trusting the wording:

Claim	Verified against
100 MiB cap	python/composio/core/models/_files.py:57 and ts/packages/core/src/utils/readResponseBody.ts:2 — both 100 * 1024 * 1024
Python raises ResponseTooLargeError	_files.py:738 (Content-Length pre-check) and :754 (authoritative streamed counter)
TS "error naming the byte count and the limit"	readResponseBody.ts:4 — File size (${actualSize} bytes) exceeds maximum allowed size (${maxBytes} bytes), a plain Error, so the docs are right not to name a catchable type here
Partial download discarded	_files.py:759 → _discard_partial_download(outfile); TS buffers before saveFile, so nothing partial reaches disk
Workaround: fetch s3url yourself	s3url is the field name in both — FileDownloadable.s3url (_files.py:683) and value.s3url (FileToolModifier.node.ts:217)

Also correct to omit any mention of tuning the cap: maxDownloadBytes / max_size exist on the utilities, but neither auto-download call site threads them (Files.node.ts:85, FileToolModifier.node.ts:169, _files.py:1344), so 100 MiB is not reachable from tools.execute. "Leave automatic file handling off and fetch the s3url yourself" really is the only user-level escape hatch.

Dependency realignment is clean. All ten bumps match npm latest exactly (@composio/core 0.18.0, anthropic/claude-agent-sdk 0.11.1, google 0.10.3, langchain/llamaindex/openai-agents 0.10.2, mastra 0.10.4, openai 0.12.1, vercel 0.11.2), and docs/bun.lock resolves to those same versions. No unrelated docs touched.

---

The callout needs a version floor

Issue: the download cap is not in any installable release, and unlike the callout 15 lines below it, this one states no version floor — so it reads as describing current behavior.

• npm @composio/core latest is 0.18.0, which is what this PR pins docs to. .changeset/bound-download-size.md is still unconsumed and marked patch, and ts/packages/core/CHANGELOG.md 0.18.0 has no download-cap entry → the fix lands in 0.18.1.
• PyPI composio latest is 0.21.0. I pulled the published wheel: its _files.py has max_size only on _fetch_file_from_url (the upload path) and no _discard_partial_download at all — FileDownloadable.download is still uncapped there. python/composio/__version__.py on this branch is also 0.21.0, so the cap ships in the next Python release, which doesn't have a number yet.

A reader on either published version who downloads a 200 MB file gets it saved, not an error. This is the same gap I noted last time, but it now sits next to a callout that does declare floors (executing-tools.mdx:499: "requires @composio/core 0.17.1 or later (TypeScript) or a composio release newer than 0.20.0 (Python)"), so the omission reads as "already shipped."

Fix — append one sentence:

<Callout type="info">
Automatic downloads are capped at **100 MiB** per file, because the download URL comes from the tool response and an oversized body would otherwise exhaust memory or fill the disk. A larger file fails instead of being saved — Python raises `ResponseTooLargeError`, TypeScript throws an error naming the byte count and the limit — and the partial download is discarded. To handle bigger files, leave automatic file handling off and fetch the `s3url` from the raw tool response yourself. The cap requires `@composio/core` 0.18.1 or later (TypeScript) and a `composio` release newer than 0.21.0 (Python); earlier versions download without a size limit.
</Callout>

The TS number is pinned by the changeset; fill in the Python one when that release is cut, or keep the "newer than 0.21.0" phrasing the neighbouring callout already uses for the same reason.

Fix this →

No other issues: no wrong API usage, no missing steps, no ordering problems, and the page is existing content so no meta.json or index entry is needed. I did not change any files — this is review feedback only.
· docs/auto-sdk-sync

[socket-security]

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff	Package	Supply Chain Security	Vulnerability	Quality	Maintenance	License
	npm/​@​composio/​llamaindex@​0.10.1 ⏵ 0.10.2				-1
	npm/​@​composio/​google@​0.10.2 ⏵ 0.10.3
	npm/​@​composio/​openai@​0.12.0 ⏵ 0.12.1			+1	+1
	npm/​@​composio/​openai-agents@​0.10.1 ⏵ 0.10.2	+3		+1	-1
	npm/​@​composio/​claude-agent-sdk@​0.11.0 ⏵ 0.11.1	+2
	npm/​@​composio/​anthropic@​0.11.0 ⏵ 0.11.1	-2			+1
	npm/​@​composio/​vercel@​0.11.1 ⏵ 0.11.2	+15		+1	-1
	npm/​@​composio/​mastra@​0.10.3 ⏵ 0.10.4	+23		+1
	npm/​@​composio/​langchain@​0.10.1 ⏵ 0.10.2	+15			-1
	npm/​@​composio/​core@​0.17.0 ⏵ 0.18.0	+1		+1

View full report

[claude]

Claude finished @sdkrelease[bot]'s task in 4m 29s —— View job

---

Docs review — two fixes suggested

• Read docs/agent-guidance/agents/docs-reviewer.md
• Run git diff origin/next...HEAD
• Verify the authConfigId filter in both SDKs
• Verify the V1/V2 claim and the #webhook-payload-versions anchor
• Check version floors and the dependency realignment
• Post review

The force-push replaced the download-cap callout with a triggers change. Current diff: docs/content/docs/setting-up-triggers/subscribing-to-events.mdx:53 adds authConfigId to the subscribe filter list plus a new callout, and the ten @composio/* bumps in docs/package.json / docs/bun.lock.

What checks out. authConfigId is a real subscribe filter in both SDKs — TriggerSubscribeParamSchema (ts/packages/core/src/types/triggers.types.ts:14) and TriggerEventFilters.auth_config_id (python/composio/core/models/triggers.py:443). The #webhook-payload-versions anchor resolves (## Webhook payload versions, line 341), and the V1/V2 sample payloads there genuinely have no auth config field. All ten dependency bumps match npm latest exactly (@composio/core 0.18.0, anthropic/claude-agent-sdk 0.11.1, google 0.10.3, langchain/llamaindex/openai-agents 0.10.2, mastra 0.10.4, openai 0.12.1, vercel 0.11.2) and docs/bun.lock resolves to those same versions. No unrelated docs touched.

---

1. The filter is documented but silently ignored on the published TypeScript release

Issue: authConfigId filtering only started working in 52efb5b (this branch), which is unreleased. I pulled the published @composio/core@0.18.0 tarball — the version this PR pins docs to — and checked the bundle:

$ grep -o "does not match [a-zA-Z]* filter" package/dist/index.mjs | sort -u
does not match connectedAccountId filter
does not match toolkits filter
does not match triggerData filter
does not match triggerId filter
does not match triggerSlug filter
does not match userId filter

No authConfigId branch in shouldSendTriggerAfterFilters — but the param is in the published .d.mts (authConfigId?: string | undefined on TriggerSubscribeParamSchema). So a reader on 0.18.0 adds the filter, TypeScript accepts it, and every event still arrives. Silent wrong behavior is worse than an error, and there's no version floor on the page to warn them. .changeset/trigger-auth-config-filter.md is a patch, so the fix lands in 0.18.1.

Python needs no floor: I pulled the published composio 0.21.0 wheel and _filters_match already includes ("auth_config_id", data["metadata"]["connected_account"]["auth_config_id"]).

Fix — add a floor sentence, matching the phrasing style used for the other version callouts on the site:

authConfigId filtering requires @composio/core 0.18.1 or later (TypeScript) — earlier versions accept the filter and ignore it, delivering every event. Python filters on auth_config_id from composio 0.21.0.

Fix this →

2. The callout's V1/V2 claim doesn't hold for the subscribe() stream it sits under

Issue: the callout says an authConfigId filter "drops every V1 and V2 event" and tells legacy organizations to use connectedAccountId instead. That's true of V1/V2 webhook payloads, but the paragraph it follows is about subscribe(), and the realtime channel doesn't deliver those. Per the SDK's own comment, V1/V2 organizations get the legacy envelope over Pusher, and both SDKs read an auth config ID out of it:

• Python python/composio/core/models/triggers.py:606-609: "The realtime (Pusher) channel delivers either the modern V3 envelope … or the legacy envelope (for V1/V2 projects)" — and :646 maps "auth_config_id": legacy["metadata"]["connection"]["authConfigNanoId"].
• TypeScript ts/packages/core/src/models/Triggers.ts:733 → transformIncomingTriggerPayload → ts/packages/core/src/utils/transformers/triggers.ts:43 sets authConfigId: response.metadata.connection?.authConfigNanoId.

So the filter generally works for legacy organizations on subscribe(), and the callout steers them off it. And in the case the callout does describe — a V1/V2-shaped frame arriving over the WebSocket — Python doesn't parse it at all (_parse_payload falls into the legacy branch, legacy["metadata"] raises, the frame is logged and skipped), so switching to connectedAccountId wouldn't recover those events either.

Worth noting the source comment added by the same fix keeps the parenthetical the docs dropped: "Only V3 trigger payloads (and the legacy TriggerData shape) carry an auth config id" (Triggers.ts:561-563).

Fix — narrow the claim to what actually gets dropped:

<Callout>
An `authConfigId` filter only matches events that carry an auth config ID: [V3 payloads](#webhook-payload-versions) and the legacy realtime envelope that V1/V2 organizations receive over `subscribe()`. Events without one — V1/V2-shaped frames, and non-trigger V3 events such as connection-expired notifications — are dropped. Filter by `connectedAccountId` if you need those too.
</Callout>

Fix this →

---

Non-blocking: the filter list on line 53 is camelCase, but Python's kwargs are snake_case and one name differs (toolkit, not toolkits) — TriggerEventFilters is trigger_slug, trigger_id, toolkit, user_id, auth_config_id, connected_account_id. handle(**filters) silently ignores unknown keys, so a Python reader who copies authConfigId= gets no filtering and no error. That's pre-existing for the other five names; this PR just adds a sixth. Worth a follow-up that gives the two languages' names separately.

No other issues: no wrong API usage, no missing steps, no ordering problems, and the page is existing content so no meta.json or index entry is needed. I did not change any files — review feedback only.
· docs/auto-sdk-sync