This PR:
- closes#4028
- removes the unused `isNewerVersion` helper from the internal version
utility
- avoids defining malformed-version behavior for a helper with no
callers or package export
- retains `next`'s tested npm version-check timeout implementation
- adds a patch changeset for `@composio/core`
- refreshes Python 3.12.13 artifact metadata in `mise.lock` after the
upstream build was republished
## Verification
- version utility tests: 2 passed
- core typecheck: passed
- changeset validation: passed
- `mise 2026.5.18 lock --platform
linux-x64,linux-arm64,macos-arm64,macos-x64`: clean
---------
Co-authored-by: jkomyno <alberto@composio.dev>
Fixes#4026
## Problem
The `Composio` constructor fires a background npm version check unless
`disableVersionCheck` is set — and `disableVersionCheck` has no default,
so this is on for every user:
```ts
// ts/packages/core/src/composio.ts:399-402
if (!this.config.disableVersionCheck) {
checkForLatestVersionFromNPM(version);
}
```
That check performed a bare fetch with no timeout and no AbortSignal:
```ts
// ts/packages/core/src/utils/version.ts:46
const response = await fetch(`https://registry.npmjs.org/${packageName}/latest`);
```
An in-flight fetch keeps its socket referenced on the Node event loop.
When registry.npmjs.org is slow, black-holed, or
unreachable-but-accepting (corporate proxy, egress firewall that drops
rather than rejects, captive network, npm incident), the process cannot
exit — all the user's work is done and it just sits there. It's also
called without await, so a caller has nowhere to attach a bound of their
own.
Reproducing with a local server that accepts the socket and never
responds: the process was still alive at 90s and had to be killed.
## Fix
```diff
- // @TODO: Check if fetch is available, if not use node-fetch
- const response = await fetch(`https://registry.npmjs.org/${packageName}/latest`);
+ const response = await fetch(`https://registry.npmjs.org/${packageName}/latest`, {
+ signal: AbortSignal.timeout(VERSION_CHECK_TIMEOUT_MS),
+ });
```
`VERSION_CHECK_TIMEOUT_MS = 2000`. The existing `catch (_error) { /*
Ignore and do nothing */ }` already swallows the resulting
`TimeoutError`, so failure stays silent — which is right for a
best-effort nicety nobody awaits. A comment records why the signal is
there so a later cleanup doesn't drop it.
Also removed the stale `@TODO: Check if fetch is available, if not use
node-fetch` on the line above: the code already calls global `fetch`
unconditionally, and `toolchain-versions.json` pins the tested Node
versions to 22/24/25, where both `fetch` and `AbortSignal.timeout` (Node
17.3+) are available.
## Results, and one honest caveat
End-to-end with the issue's reproduction: 91s, exit 124 (killed) →
exited on its own after 6.0s, exit 0.
That 6.0s deserves explanation, because the timeout is 2s and I did not
want to overclaim. Measured in isolation:
```text
fetch rejected at 2.01s with TimeoutError <- the signal works as intended
handler done at 2.01s
process exited at 6.03s <- undici's default 4s keepAliveTimeout
```
So the SDK's wait is bounded at 2s, which is what this change controls.
The trailing ~4s is Node's global undici agent releasing the pooled
socket, outside this code's reach — I tested `connection: 'close'` to
see if it could be shortened and got an identical 6.03s. Eliminating it
would require a custom dispatcher, which isn't worth the complexity for
a background version check. Net: unbounded becomes bounded, worst-case
exit ~6s instead of never.
## Tests
Added `ts/packages/core/test/utils/version.test.ts` with two focused
regressions:
- asserts `AbortSignal.timeout` receives `2_000` and its exact signal is
passed to the registry request
- proves that aborting a registry request that never responds is
swallowed by the best-effort check
The timeout path uses a controlled `AbortController`, so the test is
deterministic and does not wait two seconds of wall-clock time.
## Verification
| Check | Result |
|---|---|
| Focused version-check tests | 2 passed |
| Full core suite | 1046 passed |
| Core typecheck | exit 0 |
| Core build | passed, including ATTW and publint |
| Package lint | exit 0 with existing repository warnings |
| Changeset validation | passed |
## Out of scope — follow-up worth filing
`TelemetryService.sendMetric` / `sendErrorLog`
(`services/telemetry/TelemetryService.ts:14,35`) have the identical
unbounded-fetch shape. Black-holing `telemetry.composio.dev` still hangs
the process indefinitely with this fix applied:
```text
blackhole=[registry] -> exited after 6.0s
blackhole=[telemetry] -> HUNG (killed at 45s)
```
I deliberately left it alone: telemetry has its own
`registerExitHandlers`/`flush` machinery that intends to block on exit,
so bounding it is a real design decision rather than a one-liner, and
it's outside what this issue covers. Happy to open a separate issue for
it.
## Notes
- Changeset included (`@composio/core: patch`).
- The Python SDK has no equivalent version check, so no parity change is
needed.
Keeps this branch's fixture-driven managed-block reconciler
(reconcileManagedPathBlock, pinned byte-for-byte against install.sh's awk
rewrite by test/managed-block-fixtures) and drops next's narrower
replaceManagedPathBlock/applyFileChanges pair, which it supersedes.
Adopts from next: the narrowed unsafe-path character set on both the TS and
sh sides, the removal of the $PATH-reachability write skip, the hedged
no-shell PATH message, and the COMPOSIO_BIN_DIR command documentation.
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.
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.
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`
The /install/<shell> variant routes still 404 in production, so the
harness's prod mode now selects the shell with COMPOSIO_INSTALL_SHELL on
the base /install route, and the scheduled matrix gains a fish leg. The
Docker harness invocation stays in place; a workflow comment records how
to restore variant-route coverage once the routes ship.
The previous installer wrote marker + export COMPOSIO_INSTALL_DIR + PATH
export. Both the shell and TypeScript reconcilers now consume that triple
as one managed block instead of orphaning the export lines, with shared
legacy-migrate and near-miss fixtures keeping the two implementations
byte-identical.
Port the atomic replacement work from #4016: support files publish first,
release metadata next, the binary last, with aside/rollback recovery for
directory entries and preserved staging on failed restores.
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.
Ten comments across install.sh, install.cmd.ts, and the harness cited
KD2/KD3/KD4/KD7 decisions from a plan file that exists on no branch.
Rewrite each comment to carry its constraint inline — the truthful
final action block, delegation trust via physical path comparison,
non-fatal setup failures, and copy-paste-safe endings — and drop the
dangling references.
The CLI and install.sh implemented the managed-PATH-block contract
twice with three divergences: TS matched marker lines after trimming
while the sh awk program matches byte-exact (CRLF or padded markers
reconciled on one side and duplicated on the other), TS replaced stale
blocks in place while sh removes managed lines and appends the fresh
block, and renderWithHome rendered a bin dir equal to $HOME as the
$HOME literal while render_bin_dir left it as the raw path — making
delegated verification permanently stale for that layout.
Align both sides: TS goes byte-exact and remove-then-append (mirroring
the awk program including its newline normalization), and
render_bin_dir learns the $HOME-exact case. A shared fixture suite
under test/managed-block-fixtures now runs against both reconcilers —
vitest drives the exported TS functions, the harness sources
install.sh's definitions and runs write_path_block under sh and dash —
so future edits to one side fail loudly until the other matches byte
for byte.
Three from-scratch tmp-write→rename implementations coexisted
(install.cmd.ts, tool-permissions writeCacheFile, analytics
writeAnalyticsStateFile), and the install ones raced concurrent installs
through a fixed .composio-tmp suffix. Extract src/utils/atomic-write.ts:
the tmp name embeds the pid, an optional preserveMode creates the tmp
with the target's mode and pins it via chmod, and the best-effort tmp
cleanup now also covers a failure of the initial write itself (ENOSPC
mid-write no longer leaves tmp litter). All three call sites migrate
with their semantics intact; tests scan for any .composio-tmp remnant
instead of probing the old fixed name. Extracting the block-append loop
also brings installShellIntegration back under the function-length
lint that the merge had pushed over.
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.
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.
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.
A login bash reads /etc/profile and then only the first existing of
~/.bash_profile, ~/.bash_login, ~/.profile; it never reads ~/.bashrc.
macOS Terminal.app starts exactly such a shell, so a terminal opened
after installation could not resolve composio even though the installer
reported success.
Always configure a login-mode startup file alongside ~/.bashrc: reuse an
existing ~/.bash_profile or ~/.bash_login, otherwise create
~/.bash_profile seeded to keep sourcing ~/.profile, which it shadows.
~/.profile itself is never rewritten.
Also refine the shell setup reporting:
- capture the delegated `composio install --shell` output so the
installer keeps sole ownership of its presentation, replaying it under
COMPOSIO_DEBUG so failures stay diagnosable
- drop the internal (cli)/(fallback) labels from user-facing output
- name the configured startup files from both the delegated and inline
paths, so piped installs disclose which files changed
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.
Apply verified code-review findings: write through symlinked startup
files with preserved mode and a per-process tmp name; verify delegated
CLI setup actually reconciled the managed block before trusting exit 0;
make managed-block reconciliation assignment-aware so annotated blocks
never lose user content or PATH precedence; clean up the CLI's tmp file
when an atomic write fails; assert the auto contract in the install
health-check canary; recommend composio install --shell in generated
release docs; record the new default in the CLI changelog.
COMPOSIO_INSTALL_SHELL grows auto (the new default) and none. auto
infers the login shell from $SHELL and always runs idempotent setup
for recognized shells; none keeps install-only behavior for CI and
dotfile managers. Final output follows the KD4 state matrix against a
pre-install PATH snapshot with physical-path identity, setup failures
never fail the install, and the managed PATH block reconciles stale
bin directories.
Rajarshi Datta