[feat] Record members' TeamAI installation methods and make Hook updates target known npm-global copies

Open
  • Is something wrong?
#1,753 2 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
38/100
Issue type
Feature
Clarity
Clearly specified
Activity status
Active
Tech stack
node.js, typescript
Domain
backend, cli, devtools

Research direction

Start by locating the Hook Stop update path, the existing autoUpdate/updatePolicy handling, machine update lock, and member/diagnostic reporting views. Trace how the running package and registered installations are identified, then compare that flow with the acceptance checks for explicit npm prefixes, verification, and reporting privacy. Done means the listed checks hold, including that unsupported layouts and skip/prompt policies never trigger npm installation.

Written by the indexing model from the issue text.

Description

enhancement help wanted

Problem

A team can have different TeamAI versions installed through different managers. A member can also have several copies on the same machine. The terminal's which teamai and teamai -V do not necessarily identify the package a generated Hook launches.

Sanitized examples from a team investigation:

Copy reported Entry Version
npm global under Homebrew prefix /opt/homebrew/bin/teamai 0.28.1
Volta-managed copy on the same machine <HOME>/.volta/bin/teamai 0.29.0
Another member's nvm installation <HOME>/.nvm/versions/node/v24.14.0/bin/teamai 0.22.0

The first entry was resolved to /opt/homebrew/lib/node_modules/teamai-cli/dist/index.js: it is an npm-global installation under the Homebrew prefix, not evidence that Homebrew owns the package. The same machine's captured Hook environment selected the Volta copy.

The other member supplied only their terminal version and path. Their Hook launch path, effective update policy and historical failure reason are still unverified. An older version alone does not establish why an update failed.

Requested behavior

  1. Record the package a Hook actually runs, its version, install method, whether automatic updating is supported, effective update policy and last update result. Where reporting is enabled, let existing member/diagnostic views show a minimal summary for each observed installation.
  2. Discover the current package, PATH-visible copies and previously registered local copies. Do not scan all home directories or all nvm versions.
  3. With the existing autoUpdate / updatePolicy settings allowing it, let Stop hooks update recognized and registered npm-global copies using each copy's explicit prefix, including nvm and npm under a Homebrew prefix.
  4. Use the existing machine update lock and a bounded amount of work per Hook; updating at most one outdated copy per Stop is one option.
  5. Verify the version in the intended installation after npm exits. Do not count npm exit 0 alone as success, or upgrade a different default prefix.
  6. Record Volta and other unsupported layouts and show the appropriate manual remedy. Do not npm-install into a Volta image or invoke sudo.
  7. Updating a different copy should not silently rebind the active session's shared Hooks to that copy.

Data and policy boundaries

Keep absolute paths and executable targets local. Shared summaries can use opaque installation IDs, versions, method/category and outcomes. Honor existing usage-report opt-outs and preserve records from another machine using the same member account. Never execute an update command or trust an installation path supplied by a shared report.

Retain the member/team policy precedence. This proposal does not request overriding skip or turning a prompt policy into unattended installation.

Bootstrap limitation

Old installed code cannot acquire a new updater merely because a team repo's content changes. Document the one-time upgrade and Hook refresh needed to adopt this behavior, then maintain the registered copies through the new Hook path. It should be clear when an installation has not been observed and cannot yet be managed.

Acceptance checks

  • A Hook running from installation A can identify and update a registered npm-global installation B with an explicit B prefix.
  • Different PATH ordering and two npm prefixes do not cause the wrong directory to be upgraded.
  • Concurrent Stops do not install simultaneously.
  • Volta, local/source layouts and skip/prompt policies do not trigger npm installation.
  • npm returning 0 without changing the intended package is reported as a failure.
  • Optional member reporting excludes local paths, honors opt-outs and does not cause unchanged inventory to be pushed on every Hook.

This is a feature request for upstream ownership and release. No local fork has been deployed to team members.

Related defects reported separately: #1751 (shared version cache) and #1752 (updater outcomes and warning noise). This proposal concerns installation discovery, ownership and update coverage.

Dominant language
TypeScript
Stars
5.7k
Forks
486
Avg merge
13h 3m
Merged PRs (30d)
474

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from Tencent/teamai-cli

All issues in Tencent/teamai-cli

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.