## Summary
- preserve boolean, empty, null, type-array, enum, const, and
scalar-constraint semantics across every Python conversion entry point
- intersect Zod enum and const values with declared types and
constraints, including compound JSON values
- default unversioned exact validation to Draft 7 and apply inclusive
and numeric exclusive bounds independently
- run one byte-identical corpus through Python, Zod, and Effect so
accepted and rejected inputs stay aligned
- keep exact JSON Schema acceptance separate from Pydantic default
materialization
## Review follow-up (second push)
- Python: exact Draft 7 acceptance now wraps all three entry points
(`json_schema_to_pydantic_type`, `json_schema_to_model`,
`pydantic_model_from_param_schema`), so they can no longer disagree
- Python: draft-4 boolean `exclusiveMinimum`/`exclusiveMaximum` (OpenAPI
3.0 style) no longer crash conversion — exact validation falls back to
Draft 4, and the library input is translated to the numeric spelling
- Python: ECMA-only regex patterns (look-around) no longer crash
pydantic model builds — Rust-incompatible patterns fall back to Python
`re`
- Python: type arrays with sibling constraints no longer raise
`TypeError` on valid input — constraints are scoped per member before
the library sees them
- Python: integral floats satisfy `integer`, `const` intersects `enum`,
annotation-only schemas accept anything, and an optional property with
an empty `enum` tolerates absence
- Zod: typeless scalar constraints apply per instance type, and string
lengths count Unicode code points instead of UTF-16 code units
- Effect: draft-4 boolean exclusive bounds are enforced instead of
silently ignored
- `multipleOf` uses decimal scaling in all three converters (declared
`divergesFromJsonSchema` on the corpus case)
- shared corpus grows by 13 primitive cases; new property-based tests
check acceptance against real Draft 7 oracles (hypothesis + `jsonschema`
in Python, fast-check + Ajv in TypeScript)
## Verification
- Python `make chk` (ruff + mypy)
- Python pytest: 1,572 passed (5 langchain-extra tests need an env this
sandbox lacks; unchanged from base)
- `@composio/json-schema-to-zod`: 187 passed incl. 300-run fast-check
property test; typecheck + build
- `@composio/json-schema-to-effect-schema`: 133 passed; typecheck
- `@composio/core` corpus ingress tests: 61 passed
- shared Python/TypeScript corpus files are byte-identical
(shasum-verified)
- `git diff --check`
## Contributor context
This replaces four narrow proposals after independent local
reproduction:
- [#4301](https://github.com/ComposioHQ/composio/pull/4301) ·
[Glen](https://app.tryglen.com/ComposioHQ/composio/pull/4301)
- [#4302](https://github.com/ComposioHQ/composio/pull/4302) ·
[Glen](https://app.tryglen.com/ComposioHQ/composio/pull/4302)
- [#4303](https://github.com/ComposioHQ/composio/pull/4303) ·
[Glen](https://app.tryglen.com/ComposioHQ/composio/pull/4303)
- [#4307](https://github.com/ComposioHQ/composio/pull/4307) ·
[Glen](https://app.tryglen.com/ComposioHQ/composio/pull/4307)
---------
Co-authored-by: simpleqt <89645338+simpleqt@users.noreply.github.com>
## Summary
The Python SDK treated a custom tool's `original_slug` as globally
unique, rejecting valid custom toolkits that reuse common child names
such as `SEARCH`, `VERSION`, or `GREP` even though the backend-assigned
final slugs are toolkit-qualified (`LOCAL_ALPHA_GREP`,
`LOCAL_BETA_GREP`).
This ports the toolkit-qualified lookup from #3360 to Python, then fixes
three response-mapping bugs found in review and applies the same fixes
to the TypeScript SDK so both stay in parity.
## Changes
### Python (`composio`)
- Scope custom-tool collision detection and response matching by toolkit
plus original slug.
- Keep bare original-slug aliases only when unambiguous;
`session.execute("GREP")` raises with the final slugs to use when the
slug is shared.
- Preserve toolkit-qualified final slugs in `custom_toolkits()`.
- `build_custom_tools_map_from_response`: raise when a response tool has
local handles but no exact toolkit match instead of silently dropping it
or binding another toolkit's handler; only fall back to a bare match
when the response carries no toolkit identity; reject duplicate
qualified response entries; derive bare-slug ambiguity from local
definitions so omitting a sibling in the response never makes the
survivor callable by bare name.
- `custom_toolkits()` only reuses a bare alias that belongs to the same
toolkit.
- Docstring and Python session reference page state that bare-slug
execution requires a unique original slug.
### TypeScript (`@composio/core`)
- Same four fixes in `buildCustomToolsMapFromResponse` and the same
guard in `customToolkits()`.
- JSDoc and TypeScript session reference page updated.
- Changeset: patch for `@composio/core`.
### Not changed
- `COMPOSIO_MULTI_EXECUTE_TOOL` still aborts the whole batch when one
item uses an ambiguous bare slug, matching current TS behavior.
Switching to per-item errors is a cross-SDK design change left for a
follow-up.
## Type of change
- [x] Bug fix
- [ ] New feature
- [ ] Refactor/Chore
- [ ] Documentation
- [ ] Breaking change
## How Has This Been Tested?
Python:
- `pytest tests/test_custom_tools.py tests/test_tool_router.py`: 181
passed.
- ruff (project config) clean; mypy reports no errors in the touched
files.
- New tests: sibling routing, multi-execute, preload rejection, listing
guard, and five response-mapping cases (no exact match, cross-toolkit
binding, standalone bare fallback, unknown response tools skipped,
ambiguity from local definitions, duplicate qualified entries).
TypeScript:
- `vitest run` in `ts/packages/core`: 53 files, 1251 passed, 2 expected
failures.
- `tsc --noEmit` clean; prettier and oxlint via pre-commit hook.
- New tests: cross-toolkit reuse in `buildCustomToolsMap` and a new
`buildCustomToolsMapFromResponse` block mirroring the Python cases.
Python and TypeScript CI do not run automatically on this fork PR; a
maintainer needs to approve the workflow run.
## Checklist
- [x] I have read the Code of Conduct and this PR adheres to it
- [x] I ran linters/tests locally and they passed
- [x] I updated documentation as needed
- [x] I added tests or explain why not applicable
- [x] I added a changeset if this change affects published packages
## Additional context
Reviewed with a second opinion from Codex (gpt-5.6-sol), which flagged
the wrong-handler binding and response-derived ambiguity bugs fixed in
the follow-up commits.
https://claude.ai/code/session_01Y7Ni3QEBDGShSrEtwQS5bA
EOF -R ComposioHQ/composio
---------
Signed-off-by: CoralGarden52 <2193436736@qq.com>
Co-authored-by: jkomyno <alberto@composio.dev>
Co-authored-by: Alberto Schiabel <jkomyno@users.noreply.github.com>
## Summary
- Apply the existing authConfigId subscription filter to incoming
trigger events.
- Add a V3 regression test for mismatched auth configurations.
- Add a patch changeset for @composio/core.
Previously, a subscription filtered by authConfigId still invoked its
callback for events belonging to a different auth configuration.
## Verification
- Vitest targeted tests: 76 passed
- Vitest core suite: 1244 passed, 2 expected failures
- TypeScript typecheck and Prettier passed
Fixes the missing authConfigId filtering in trigger subscriptions.
---------
Co-authored-by: jkomyno <alberto@composio.dev>
## Summary
- map Python file-fetch failures that occur after response headers into
the documented upload and download errors
- map TypeScript RemoteFile connection and streamed-body failures into
RemoteFileDownloadError while preserving blocked-URL errors
- close or cancel response bodies on every exit and apply the shared 100
MiB response limit to TypeScript RemoteFile downloads
This supersedes the Python-only proposal in #4305 and carries the same
failure category across both SDKs.
## Independent reproduction
A response double returned one chunk and then raised a connection-reset
error. On current next:
- Python _fetch_file_from_url leaked ConnectionError, although it did
close the response
- Python Tool Router URL fetch leaked ConnectionError and left the
response open
- TypeScript RemoteFile leaked the native fetch/body TypeError instead
of RemoteFileDownloadError
## Verification
- Python make chk
- Python make tst: 1,490 passed
- TypeScript core typecheck
- TypeScript core tests: 1,245 passed, 2 expected failures
- TypeScript package build: 19 packages
- focused Python regression tests: 3 passed
- focused TypeScript RemoteFile tests: 17 passed
## Summary
- route attacker-controlled URL sources and API-provided presigned
upload destinations through the runtime-conditional core SSRF guard
- expose that guard through a Node/workerd-aware core subpath
- validate and revalidate DNS on redirects, pin Node and Bun connections
to validated addresses, and preserve configured proxy routes
- fail closed for user-chosen URL uploads in edge runtimes
- cancel ignored response bodies and cover both upload boundaries at the
public CLI pipeline
- avoid adding `Content-Length: 0` to bodyless Bun GET requests
## Local reproduction
On `next`, the CLI pipeline used bare `fetch` for both targets. A local
loopback source and an internal presigned destination reached the
network path. With this branch, the real `uploadToolInputFiles` pipeline
blocks a `127.0.0.1` source before presigning and a `169.254.169.254`
destination before sending bytes.
A direct Bun proof also confirmed the pinned transport reaches a
validated address without calling native `fetch`, while retaining the
original Host header. Focused tests preserve native Bun fetch when an
environment proxy is configured.
## Cross-SDK parity
Python already applies public-address validation, redirect checks, DNS
pinning, and response limits to URL uploads. Its focused URL-safety and
upload suite remains green: 62 passed. No Python behavior change was
needed.
## Verification
- `pnpm build:packages`: 19 packages built
- root `pnpm typecheck`: 14 package checks passed
- TypeScript core: 53 files, 1,246 passed and 2 expected failures
- focused core SSRF and pinned-transport tests: 31 passed
- Python URL-safety/upload tests: 62 passed
- real Bun execution of both CLI upload boundaries: blocked before
presign/send
- `git diff --check`
The CLI Effect test file contains source and presigned-destination
regressions and typechecks. Its local runner is blocked on current
`next` by the repository-wide `@effect/vitest` config failure; hosted
CLI checks exercise that boundary.
## Contributor context
Supersedes [#4299](https://github.com/ComposioHQ/composio/pull/4299) ·
[Glen](https://app.tryglen.com/ComposioHQ/composio/pull/4299) after
independently reproducing the attack path. The report is valid and
useful, but the proposed root export hard-coded a Node module into an
edge-capable package, its happy-path test did not execute the returned
Effect, and it omitted destination protection, response cleanup, and Bun
address pinning.
This PR:
- closes#4284
- makes `mise.toml` the editable source of truth for Bun and pins
`1.4.1-canary.1+d9b769812`, the first Bun build whose compiled macOS
binaries carry strictly valid signatures
- maps that revision to the immutable per-platform `@oven/bun-*` npm
tarballs via mise's `http` backend, so mise extracts the exact
checksum-verified binary with no npm lifecycle, Node dependency, or
postinstall script
- installs Bun through mise in CI and Docker E2E images, removing the
independent `bun-version` input and the `oven-sh/setup-bun` channel
- updates the checksum-verified mise installer to `2026.8.15`, reuses it
in the Docker E2E images, and regenerates `mise.lock` with that release
- teaches the preinstall toolchain check to compare the full Bun
revision (via `Bun.version_with_sha`, in-process) when the pinned
version carries build metadata
- verifies the exact `bun --revision`, a strictly valid Bun-compiled
macOS signature, a Linux container install, the release-workflow
contract, and formatting/linting
EOF -R ComposioHQ/composio
## Summary
- write CLI user data, pending login sessions, and agent identities
through one atomic `0600` helper
- repair `0644` credential files created by older CLI versions before
reading them
- redact credential-shaped structured values from CLI user-context
diagnostics
- redact secret-shaped text at both TypeScript and Python SDK log-output
boundaries, including Pusher `auth` responses and exception tracebacks
- preserve Python logger compatibility: errors remain untruncated,
disabled levels remain lazy, and malformed placeholders cannot expose
arguments
## Local reproduction
Under the normal `022` umask, `next` created a plaintext credential file
with mode `0644`. The pre-fix CLI user-context and TypeScript SDK debug
paths also emitted sentinel credentials. The private atomic writer
changes an existing `0644` target to `0600`, and the upgrade tests now
prove all three legacy credential files are tightened without changing
their contents.
## Verification
- CLI permission upgrade tests: 31 passed across user data, pending
login, and agent identity paths
- CLI source and test typechecks passed
- TypeScript core logging, redaction, and Pusher tests: 17 passed
- TypeScript core source and type-test typechecks passed
- Python logging regression tests: 5 passed
- focused Ruff, Prettier, Oxlint, and `git diff --check` passed
The focused CLI runner needed a temporary local alias for the
pre-existing missing `#ssrf_guard` mapping in the CLI Vitest config. The
alias was removed after verification and is not part of this PR.
## Contributor context
Credit to **Syed Anas Mohiuddin**, independent security researcher, for
reporting the legacy CLI credential-file permission issue.
Supersedes [#4300](https://github.com/ComposioHQ/composio/pull/4300) ·
[Glen review](https://app.tryglen.com/ComposioHQ/composio/pull/4300).
The implementation also covers agent credentials, retains atomic writes,
and applies redaction at the shared SDK logging boundary.
## What the vulnerability was
The CLI's TypeScript generator wrote API-supplied tool and trigger slugs
straight into generated `.ts` files at two places where the slug becomes
**code**, not data:
- **object-literal property keys** (`PropertyValue.write`), and
- **type-declaration names** (`TypeDeclaration.write`).
Slugs are unconstrained strings (`ToolAsEnum = Schema.String`, no
character allowlist) and the threat model treats API responses as
untrusted. So a crafted slug could close the key and inject arbitrary
top-level TypeScript, which then executes when the generated SDK is
imported or built. That is remote code execution on the developer or CI
host running `composio ts generate`.
The sibling `Property` builder already got this right: it tests
`isValidJsIdentifier` and falls back to a JSON-encoded computed key.
`PropertyValue` and `TypeDeclaration` simply lacked the same guard.
## Why this change addresses it
- `PropertyValue` now applies the exact guard `Property` uses. A name
that is not a valid identifier becomes a quoted computed key
(`["..."]`), so everything it contains is parsed as a string, never as
an expression.
- `TypeDeclaration` refuses a non-identifier name with a `TypeError`. A
type name has no quoted or computed form, so quoting is not available
and failing loudly is the only safe option. The guard sits after the
existing early return for a string type body, which never writes the
name.
Output is byte-identical for every name that is already a valid
identifier, so no existing generation changes. The CLI codegen snapshots
contain only identifier-shaped slugs
(`GITHUB_ACCEPT_A_REPOSITORY_INVITATION_INPUT`) and no computed keys,
and they are unchanged.
Worth noting on the throw: the two sinks differ in exposure.
`typeDeclaration` receives the full `tool.slug` (for example
`GITHUB_FOO`), which is identifier-shaped in practice. `propertyValue`
receives `stripPrefix(tool.slug)`, which can plausibly start with a
digit for real data and now gets safely quoted rather than throwing. Any
name that would now throw was already producing syntactically invalid
TypeScript, so this converts a confusing downstream compile error into a
clear codegen error.
## Tests
**Exploit tests**, not behaviour-pinning. Nine new tests across the two
files.
The key one builds the generated object literal from a malicious slug,
evaluates it, and asserts the injected IIFE did not run:
```ts
const evaluated = new Function(`return { ${out} };`)() as Record<string, unknown>;
expect(Object.keys(evaluated)).toEqual([malicious]);
expect((globalThis as Record<string, unknown>).__PWNED__).toBeUndefined();
```
Each test was confirmed to fail against the unpatched builders and pass
after the change. On the vulnerable code the generator emits `["k"]: (()
=> { globalThis.__PWNED__ = 1; })(), ["SEND"]: "SLACK_SEND"`, which is
the payload as live code.
Existing behaviour is also pinned: valid identifier keys, well-known
symbols, optional properties, generic parameters, doc comments, and the
string-type-body short circuit.
## What was not verified
- **No end-to-end run of `composio ts generate` against a real or
malicious API response.** The fix and its tests are at the builder
layer. The call sites in
`ts/packages/cli/src/generation/typescript/generate-toolkit-sources.ts`
were read to confirm they pass attacker-controlled slugs into these
builders, but were not exercised.
- **No model-layer slug validation was added.** The finding also
suggests validating slugs against `^[A-Za-z0-9_]+$` at the model layer.
That is deliberately out of scope here: it would change what the CLI
accepts from the API and belongs in a separate, human-reviewed change.
This PR closes the two injection sinks only.
- **The `TypeDeclaration` throw is a new failure mode.** If any live
toolkit ships a slug that is not a valid identifier, codegen will now
fail loudly for it instead of emitting broken TypeScript. No such slug
appears in the repo's fixtures, but the full set of production slugs was
not enumerated.
- Python codegen was not reviewed. This finding and fix are
TypeScript-only.
## Testing performed
Clean-HEAD baseline captured before any edit: full monorepo `pnpm run
test` green, 26/26 turbo tasks, exit 0.
After the change, the same full suite is green, 26/26 tasks, exit 0.
`@composio/ts-builders` goes from 131 to 140 tests, all passing.
`@composio/cli` unchanged at 1304 passed. 20 example packages validated.
No new failures and no snapshot churn.
## Finding
Parameter finding #91 (CWE-94), validated live at
`abc8e038218305cab7f3373b82a37144fa15e630`.
Linear: https://linear.app/composio/issue/SEC-579
parameter-finding: kcy19unq784bp2z34b3299w0
Co-authored-by: Saransh <saranshrana@Saranshs-MacBook-Pro.local>
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
## Summary
- Re-exports `AnthropicTool`, `InputSchema`, and `CacheControlEphemeral`
types from `@composio/anthropic` entry point
(`ts/packages/providers/anthropic/src/index.ts`).
- Allows TypeScript users to import schema types directly without
reaching into internal paths.
## Test Plan
- Verified index exports in `@composio/anthropic`.
Keep live spinner updates within both Clack's construction-time width and the current terminal width, so resizing wider cannot reintroduce wrapped frames while narrower terminals remain clamped.
Segment messages by grapheme cluster before measuring display width so keycap and joined emoji cannot be under-counted or split.
Both spinner entry points constructed a clack spinner on stderr and
started it with a clamped message, and useMakeSpinner built a throwaway
lambda purely to relay that same clamp into createClackSpinnerHandle.
Give makeTerminalUI a startSpinner helper that both entry points call,
and let createClackSpinnerHandle take the output stream it clamps
against instead of a pre-bound closure. Behaviour is unchanged.
Claude-Session: https://claude.ai/code/session_0191yFPnWgJnzPPnCYrVm6X7
Follow-ups from review of the narrow-terminal spinner fix.
- Budget and truncate by display columns instead of UTF-16 code units.
Clack wraps the rendered frame by width, so a CJK message sat under a
`.length` budget and wrapped anyway, reinstating the leak. Walking whole
code points also keeps the cut off a surrogate pair.
- Drop MIN_SPINNER_MESSAGE_COLUMNS. The 8-column floor exceeded the row
below ~15 columns and restored the scroll it was meant to prevent. The
budget now degrades to the ellipsis, so the one-row invariant holds
wherever it can hold at all.
- Cover the paths production actually drives: live `message()` updates and
`withSpinner`'s start message. Reverting either clamp previously left the
whole suite green.
- Advance fake timers past clack's dot animation so the three dot columns
SPINNER_RENDER_OVERHEAD reserves are exercised, and run these cases
through `it.live` per the package's Effect test convention.
- Add the CHANGELOG entry this user-facing fix needs; `@composio/cli` is
changeset-ignored, so release notes go there directly.
Claude-Session: https://claude.ai/code/session_0191yFPnWgJnzPPnCYrVm6X7
This PR:
- resolves internal `$ref`/`$defs` in tool input schemas before
translation in `langchain`, `llamaindex`, `claude-agent-sdk`, `vercel`,
`google`, and `openai-agents` (`onUnresolved: 'sentinel'`)
- previously `$ref`-typed properties degraded to `z.any()` — the Zod
converter has no `$ref` branch — or were emitted as dangling references
after the root rebuild (google, openai-agents fallback)
- keeps `openai-agents`' strict-structured-outputs path untouched:
OpenAI resolves `$defs`/`$ref` natively including recursion, pinned by a
guard test
- adds per-provider `$ref` regression suites for all six providers,
including dangling-`$defs` (`GMAIL_FETCH_EMAILS`) and recursive-schema
cases
- adds a cross-provider contract test that fails when a new provider
ships without a `$ref` classification, plus property tests for
`dereferenceJsonSchema` (Python counterparts land with the Python-side
fix)
- changes the vendor-visible schema shape for `$ref`-using tools;
changeset is `minor`
## Context
The same bug was fixed locally twice before (mastra, anthropic) without
surfacing the other six providers — nothing enumerated providers and
asked the `$ref` question. The new contract test does exactly that, so
provider #11 cannot ship unclassified. Python mirrors exist already; the
Python-side provider fix follows separately.
Regenerate the cross-provider $ref contract test, the
dereferenceJsonSchema property tests, and the openai-agents
$ref contract lost in a session handoff, ported from their
surviving Python counterparts. The openai-agents non-strict
ratchet flips to a plain it now that the fallback dereferences;
the superseded openai-agents-ref.test.ts is removed in favor of
the richer contract file.
jsonSchemaToZodSchema has no $ref branch, so a $ref node degrades to
z.any() for langchain, llamaindex, claude-agent-sdk, and vercel's
default path. google and openai-agents' non-strict fallback rebuild
the root from properties/required, discarding $defs while dangling
$ref pointers survive.
Dereference internal $ref/$defs before translation in all six, using
onUnresolved: 'sentinel' so a $ref into an undeclared $defs block
(e.g. GMAIL_FETCH_EMAILS) degrades to a permissive schema instead of
throwing. The mastra and anthropic providers already had this fix;
openai-agents' strict branch is untouched since OpenAI's structured
outputs support $defs/$ref natively, including recursion, and
google's rebuild still drops additionalProperties/title/root
oneOf-anyOf-allOf beyond the dangling-$ref class this fixes.
Every other test in the package imports node builtins with the `node:`
prefix — this was the only bare `'fs'` specifier, and inconsistent with
`node:path` on the line above it.
Claude-Session: https://claude.ai/code/session_01K1hH9PMmd6KPKdkACX553z
`downloadFileFromS3` buffered the whole response with `arrayBuffer()`. The
`s3Url` it fetches is a tool-execution response field — the same untrusted
input the SSRF guard already defends against — so an oversized or endlessly
streaming body could exhaust the host process's heap.
Route the body through the existing `readResponseBodyWithLimit` guard, which
pre-checks `Content-Length` and counts streamed bytes (the header can be
absent or dishonest). The 100 MiB default matches the upload-from-URL sibling
in the same module; `maxDownloadBytes` overrides it per call.
Claude-Session: https://claude.ai/code/session_01K1hH9PMmd6KPKdkACX553z
Clack's spinner erases the previous frame by re-wrapping the raw message,
but each frame actually renders three extra prefix columns plus up to three
animated dots. Once those extras push the rendered frame across a wrap
boundary — e.g. the ~90-column upgrade message in a narrower terminal — the
erase under-counts lines and every 80ms tick leaks one, scrolling
'New version available: …' forever.
Clamp live spinner messages (start and message updates) to a single
terminal row so the redraw arithmetic cannot diverge. Stop/error messages
are single writes and stay untouched.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Extends strict-cases.json to 68 cases with shapes enumerated independently
(single-element and three-member type arrays, null-only and null-carrying
enum/const properties, nested compositions, nullable objects in arrays,
tuple and boolean items, conditional and dependency keywords, oneOf beside
anyOf, boolean and malformed properties, $ref siblings and chains, legacy
definitions next to $defs, non-string required entries, ten-level
nesting) plus null-omission pairs for nullable, composed and $ref-typed
arguments. Checks in the generator that derives the pinned JSON.
Co-authored-by: AseemPrasad <aseemprasad0520@gmail.com>
Claude-Session: https://claude.ai/code/session_01TDrxCHn2hg51HmxVstSUgs
Tuple-form items, boolean subschemas, malformed properties, oneOf left
beside anyOf, and the conditional and dependency keywords (not, if, then,
else, dependencies, dependentSchemas, propertyNames, contains,
additionalItems, unevaluatedItems, unevaluatedProperties) are now reported
as unsupported so the tool is sent without strict mode instead of with a
schema the API rejects. A root typed ["object"] is accepted, and an enum
or const that already includes null is not wrapped again.
omitNullToolArguments now follows the anyOf/oneOf branch that matches an
argument's shape, so nulls inside an object sent for a composed property
are reconciled against that branch.
Co-authored-by: AseemPrasad <aseemprasad0520@gmail.com>
Claude-Session: https://claude.ai/code/session_01TDrxCHn2hg51HmxVstSUgs
strict-cases.json (one byte-identical copy per language, next to
object-cases.json) pins the exact strict schema or the reported
incompatibilities for 44 shapes: optional widening at every depth,
nullable type arrays, compositions, enum/const wrapping, annotation
stripping, keyword-named and prototype-named properties, dynamic-key and
free-form objects, allOf/prefixItems, $defs recursion, dangling and
external refs, malformed required, non-object roots, plus null-omission
argument pairs. The TypeScript suite pins the implementation and the
Python suite checks parity against the same file.
Co-authored-by: AseemPrasad <aseemprasad0520@gmail.com>
Claude-Session: https://claude.ai/code/session_01TDrxCHn2hg51HmxVstSUgs
toStrictJsonSchema assigned rewritten property schemas by name, so a
property called __proto__ set the prototype of the properties map instead
of being stored and disappeared from the strict schema. Own properties are
now defined explicitly, matching the other schema walkers in this module.
Co-authored-by: AseemPrasad <aseemprasad0520@gmail.com>
Claude-Session: https://claude.ai/code/session_01TDrxCHn2hg51HmxVstSUgs
OpenAIAgentsProvider accepted { strict } but always registered tools with
strict: false and additionalProperties: true. Strict mode now registers
tools with strict: true and a schema normalized by toStrictJsonSchema
(optional parameters required-nullable), drops null arguments the tool
schema rejects before execution, and registers tools strict mode cannot
express without strict mode with a warning.
Co-authored-by: AseemPrasad <aseemprasad0520@gmail.com>
Claude-Session: https://claude.ai/code/session_01TDrxCHn2hg51HmxVstSUgs
MastraProvider strict mode used the root-only, input-mutating
removeNonRequiredProperties, so "strict" meant something different from
the OpenAI providers. It now runs the same toStrictJsonSchema rewrite:
optional parameters become required-nullable, tools strict mode cannot
express keep their original schema with a warning, and null arguments the
tool schema rejects are dropped before execution.
Co-authored-by: AseemPrasad <aseemprasad0520@gmail.com>
Claude-Session: https://claude.ai/code/session_01TDrxCHn2hg51HmxVstSUgs
OpenAI structured outputs support local $ref pointers, including recursive
definitions, so toStrictJsonSchema no longer inlines them: $defs and
definitions are normalized where they are declared, an optional $ref
property is widened with an anyOf null branch, and external or dangling
$refs are reported as unsupported. omitNullToolArguments follows local
$refs when deciding whether a null is accepted. The Vercel provider still
inlines definitions before converting to Zod, which does not follow $ref.
Co-authored-by: AseemPrasad <aseemprasad0520@gmail.com>
Claude-Session: https://claude.ai/code/session_01TDrxCHn2hg51HmxVstSUgs
VercelProvider strict mode now widens optional parameters to nullable
instead of dropping them, keeps the original schema for tools strict mode
cannot express, and drops null arguments the tool schema rejects before
execution. The README and docs page described the old dropping behavior.
Co-authored-by: AseemPrasad <aseemprasad0520@gmail.com>
Claude-Session: https://claude.ai/code/session_01TDrxCHn2hg51HmxVstSUgs
OpenAIResponsesProvider emits the strict schema and strict: true only when
the rewrite is lossless; otherwise the tool keeps its original schema with
strict: false and a warning names the tool and path. Tools without
parameters get a canonical empty closed object. Null arguments the tool
schema rejects are dropped before execution.
Co-authored-by: AseemPrasad <aseemprasad0520@gmail.com>
Claude-Session: https://claude.ai/code/session_01TDrxCHn2hg51HmxVstSUgs
toStrictJsonSchema now follows the contract OpenAI documents for structured
outputs: every property becomes required and optional ones are widened to
accept null, so the model keeps every parameter it could pass before. Type
arrays stay as they are (the API accepts them and rejects type next to
anyOf), so nullable objects stay nullable. Constructs strict mode cannot
express (objects with arbitrary keys, allOf, prefixItems, unresolved $refs,
non-object roots) are reported in `unsupported` instead of being narrowed.
omitNullToolArguments drops a null argument only where the tool's own
schema rejects it, so nullable fields keep an explicit null. The keyword
taxonomy shared by the three schema walkers now lives in one place.
Co-authored-by: AseemPrasad <aseemprasad0520@gmail.com>
Claude-Session: https://claude.ai/code/session_01TDrxCHn2hg51HmxVstSUgs
# Description
Found by the scheduled security audit while reviewing the CLI release
pipeline.
`ts/packages/cli/scripts/_acp-adapters.ts` downloads four
`@zed-industries/codex-acp-<platform>` tarballs directly from the
registry at release-build time — it has to, because `pnpm` only installs
the optional dependency matching the runner's own platform while the
archive must name all four. Those bytes were then extracted, `chmod
0755`'d, and packaged inside the published `composio` CLI archive
**without being checked against any known hash**.
That made the codex-acp binaries the one dependency in the release that
received none of the integrity verification `pnpm install
--frozen-lockfile` applies to everything else, despite `pnpm-lock.yaml`
already pinning a `sha512` for each of them:
```
'@zed-industries/codex-acp-linux-x64@0.16.0':
resolution: {integrity: sha512-xs5zZBLpJuciEbZNx6ZSNL0qCa9h3i/zWpj40sp6QtF+L4Ow/7qzHdBzboGhHdcz1jrLedfZeRFDA2Elj8TLMA==}
```
Distribution is `curl -fsSL https://composio.dev/install | sh`, so
anything that reached those bytes between the registry and the archive
would ship executable to every CLI user inside an otherwise-signed
release.
## What changed
New `scripts/_tarball-integrity.ts`:
- `parseLockfileIntegrity` — maps every `name@version` in
`pnpm-lock.yaml` to its recorded hash. Line-based rather than a YAML
parse: the shape being read is two adjacent lines, and this keeps a
build script free of a YAML dependency.
- `expectedIntegrityFor` — returns the pinned hash, and **throws** for a
package the lockfile never resolved.
- `assertBytesMatchIntegrity` — Web Crypto digest compared against the
pinned value; the algorithm is read from the expected string so a
lockfile that moves off sha512 keeps working.
- `findLockfilePath` / `loadLockfileIntegrity` — walk up from the script
rather than resolving a fixed `../../..`.
`_acp-adapters.ts` now looks the hash up *before* the download and
verifies the archive bytes before extracting them.
Two deliberate choices:
- **Checked against the lockfile, not the registry's `dist.integrity`**
— whoever can serve the tarball can serve the metadata that vouches for
it.
- **Fail-closed throughout** — a missing lockfile, or a package absent
from it, aborts the build rather than packaging unverified bytes.
Scope is limited to the integrity gap. The `@zed-industries/codex-acp*`
family is deprecated upstream ("replaced by
`@agentclientprotocol/codex-acp`") and pinned at `0.16.0`; migrating it
is a separate call for whoever owns the ACP integration.
# How did I test this PR
**Unit — 16 new tests, all passing:**
```
$ vitest run test/src/scripts/tarball-integrity.test.ts
Test Files 1 passed (1)
Tests 16 passed (16)
```
Covers quoted scoped keys and unquoted bare keys, resolutions carrying
no integrity, `snapshots:` repeats, a package absent from the lockfile,
a version pinned under a different number, tampered bytes, a single
flipped byte, an uncomputable algorithm, sha256 as well as sha512, and
the upward lockfile walk (including the no-lockfile-anywhere case). One
test asserts this repository actually pins a hash for all four packaged
codex-acp binaries.
**Live end-to-end against the real registry** — the real 74,914,872-byte
`@zed-industries/codex-acp-linux-x64@0.16.0` tarball, downloaded and run
through the same code path the build uses:
```
downloaded 74914872 bytes from https://registry.npmjs.org/@zed-industries/codex-acp-linux-x64/-/codex-acp-linux-x64-0.16.0.tgz
PASS: real tarball matches the lockfile pin
PASS: tampered rejected — TarballIntegrityError: Integrity mismatch for @zed-industries/codex-acp-linux-x64@0.16.0.
PASS: unpinned version refused — TarballIntegrityError: @zed-industries/codex-acp-linux-x64@0.99.0 has no integrity hash in pnpm-lock.yaml; refusing to package unverified bytes.
```
So the check passes on genuine bytes, rejects a single flipped byte in a
75 MB archive, and refuses a version the lockfile does not pin.
**Lint / types / boundaries:**
- `oxlint` on all three files — clean. (First draft used `node:crypto`;
`no-restricted-imports` bans it, so the digest went to Web Crypto.)
- `prettier --check` — clean.
- `tsc --noEmit` — no errors in any of the three changed files. This
sandbox has 820 pre-existing errors from an unbuilt workspace (only 7 of
70 projects installed); `test/src/scripts/release-artifacts.test.ts`
fails to import here for the same reason, on `next` as well as on this
branch.
- `pnpm run validate:boundaries` — `lint boundaries OK: 4 registered
disables across 4 files` (unchanged; `scripts/` and `test/` sit outside
the `src/` Effect boundary policy).
# Security
- **Grype** — `grype dir:ts/packages/cli/scripts --only-fixed --fail-on
medium` → `No vulnerabilities found`.
- **Socket** — could not run. `doppler secrets get SOCKET_API_TOKEN
--plain --project hermes --config dev_zen` returns empty in this cron
sandbox, so `socket ci` exits with `Auth Error`. Reporting rather than
skipping silently; this change adds no dependency, so the
dependency-alert surface is unchanged.
- No new dependencies, no new network destinations. The one behavioural
change is a fail-closed integrity check on bytes that were previously
trusted unverified.
Origin: cron-48e51eab745f /
[zen-cron-44e260352d1a](https://zen.corp.composio.io/dashboard/#/chat/zen-cron-44e260352d1a)
Triggered by: saransh@composio.dev | Source: unknown
Session:
https://zen.corp.composio.io/dashboard/#/chat/zen-cron-44e260352d1a
# Description
Found by the scheduled security audit, while checking whether a test
failure on my other PR was pre-existing. It was — and the reason it
fails is a real gap in a shipped security control.
`isBlockedSensitiveFileUploadPath` (the GHSA-hp3h-89pf-5q58 denylist)
matched deny segments **only against the symlink-resolved path**. That
catches a benign name pointing at a secret — `~/innocent-name ->
~/nested/.aws/creds`, which the existing test covers — but misses the
inverse:
| Layout | Written path | Resolved path | Blocked before? |
|---|---|---|---|
| `~/innocent -> ~/.aws/creds` | no `.aws` | **`.aws`** | yes |
| `~/.claude -> /state/claude` | **`.claude`** | no `.claude` | **no** |
`~/.claude/settings.json` resolves to `/state/claude/settings.json`,
which has no `.claude` segment, so it sailed through — and `.claude` is
on the denylist precisely because it *"may contain API keys and project
context read by assistants"*.
This layout is not exotic. Dotfile managers (chezmoi, stow, yadm) and
containerised home directories produce it routinely — Composio's own
agent sandbox image has `/home/zen/.claude -> /state/claude`. For every
user in that shape the control was silently inactive, which is the worst
failure mode for a denylist: no error, no warning, upload proceeds.
The same hiding trick applies to the basename check (`~/.env ->
/state/plain-config`), so that path is fixed too.
## Why CI never caught this
`ts/packages/core/test/utils/sensitiveFileUploadPaths.test.ts` **already
asserts** the blocked behaviour:
```ts
expect(isBlockedSensitiveFileUploadPath(path.join(os.homedir(), '.claude', 'settings.json'))).toBe(true);
```
That assertion has been failing on `next` on any machine where
`~/.claude` is a symlink. It passes in CI only because `~/.claude` does
not exist on the runners: `existsSync` is false, no `realpath` runs, and
the written path keeps its `.claude` segment. The test is
environment-dependent, so green CI was never evidence the control
worked.
## The fix
The TypeScript `normalizePath` helper now returns both the written and
resolved segments, and the segment scan and basename check each consider
both. The Python guard now applies the same rule. Either path can carry
the denied name, so both SDKs inspect both forms.
# How did I test this PR
**The TypeScript fix is gated by tests — 3 fail without it, 13/13 pass
with it.**
Without the `src` change (test file only):
```
× blocks common credential directory segments
× blocks a sensitive directory that is itself a symlink to a plain path
× blocks a denied basename whose symlink target is named innocuously
Tests 3 failed | 10 passed (13)
```
With the fix:
```
Test Files 1 passed (1)
Tests 13 passed (13)
```
Note the first of those three is the **pre-existing** assertion quoted
above — this PR turns it green rather than adding it.
Three tests added, each building a real symlink in a temp dir:
- sensitive directory that is itself a symlink to a plain path (the
`~/.claude -> /state/claude` case), asserting both
`isBlockedSensitiveFileUploadPath` and that `assertSafeFileUploadPath`
throws
- denied basename whose symlink target is named innocuously (`.env ->
plain-config`)
- **negative case**: an ordinary file reached through a symlinked
directory (`docs/document.pdf`) is still allowed, so the fix does not
over-block
The Python parity change adds the same three cases. Before the Python
source change, the sensitive written directory and basename both
returned `False`; with the fix, all 11 focused Python tests pass.
**Full verification:**
| Command | Result |
|---|---|
| `vitest run` in `ts/packages/core` | **48 files, 1114 tests passed** |
| `pnpm typecheck` (workspace) | **14/14 tasks successful**, exit 0 |
| `oxlint` on both changed files | exit 0, clean |
| `prettier --check` on both changed files | "All matched files use
Prettier code style!" |
| `nox -s chk` in `python/` | Ruff and mypy passed |
| `nox -s tst` in `python/` | **1339 passed, 33 skipped**, exit 0 |
# Security
- No dependency changes, no new network calls, no new imports. The diff
is limited to the equivalent TypeScript and Python guards, their tests,
and the required `@composio/core` patch changeset.
- This **strengthens** an existing control and cannot weaken it: the
previous match set is a strict subset of the new one, so nothing that
was blocked before is allowed now. The added negative test pins that the
widening does not over-block ordinary files.
- **Grype** — `grype dir:ts/packages/core --only-fixed --fail-on medium`
→ reported below.
- **Socket** — could not run; `doppler secrets get SOCKET_API_TOKEN
--plain --project hermes --config dev_zen` returns empty in this cron
sandbox, so `socket ci` exits `Auth Error`. Reporting rather than
skipping silently.
- Unrelated pre-existing note: the repo's `pnpm audit --prod` comment
flags `extract-zip <=2.0.1` with `Patched versions >=2.0.2`, a version
that does not exist on npm. Details in #4217.
Origin: cron-48e51eab745f /
[zen-cron-44e260352d1a](https://zen.corp.composio.io/dashboard/#/chat/zen-cron-44e260352d1a)
Triggered by: saransh@composio.dev | Source: unknown
Session:
https://zen.corp.composio.io/dashboard/#/chat/zen-cron-44e260352d1a
## Summary
Updates docs and sample scripts to use latest Gemini models.
## Changes
- Vertex & Gemini sample scripts updated
- Plus accompanying markdown
## Type of change
- [ ] Bug fix
- [ ] New feature
- [ ] Refactor/Chore
- [x] Documentation
- [ ] Breaking change
## How Has This Been Tested?
Visual inspection
## Checklist
- [x] I have read the Code of Conduct and this PR adheres to it
- [x] I ran linters/tests locally and they passed
- [x] I updated documentation as needed
- [ ] I added tests or explain why not applicable
- [ ] I added a changeset if this change affects published packages
## Additional context
Alberto Schiabel