pull and doctor never update or remove a delivered skill whose delivery record is lost when the team clone is checked out with CRLF (core.autocrlf=true)

Open
  • Is something wrong?
#1,743 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
32/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
typescript
Domain
cli, devtools, security

Research direction

Start by reading the pull, doctor, and skill delivery code paths, then trace how per-tool delivery records are stored and used to decide ownership. The report also points to fan-out configuration, hook dispatch, secret screening, and doctor output; assess each concern separately. Done means the reported ownership and delivery failures are reproducible and the chosen behavior is covered by focused tests.

Written by the indexing model from the issue text.

Description

bug help wanted

Summary

On Windows 11 x64, teamai-cli 0.28.1 (user scope, provider CNB), I hit three converging problems during real usage. Most impactful: after delivery records were lost, pull reclassifies files teamai itself had delivered as "the member's" and refuses to update or remove them — from the user side this looks like "deleted skills keep coming back / can never be cleaned". Sanitized evidence below; happy to run any diagnostic you need.

Environment

  • Windows 11 x64, teamai-cli 0.28.1 (0.29.0 offered as update)
  • scope: user, provider: cnb (team repo on cnb.cool/<org>/<repo>)
  • 13 agent tool dirs detected on this machine: claude, codex, cursor, copilot, qoder, qoder-cn, zcode, codebuddy, dsh, workbuddy, opencode, trae, trae-cn
  • Onset time unknown (sorry — can't pin the version); local debug log goes back to 2026-10-27T10:31:42Z, so the timeline is traceable from there

Problem 1 [main]: pull misjudges its own delivered files as "the member's" once delivery records are lost

teamai doctor (2026-11-05) reports in one tool alone:

✖ Skills delivered to trae
  → Kept C:\Users\cpero\.trae\skills\12306: it is not teamai's (no delivery record,
    and it matches no team version of skills/12306). Rename or delete it, then run
    teamai pull, to receive the team version.

…repeated for 67 skills in that tool (12306, agent-governance, agent-team, …), and similar "no delivery record" lines appear for other tools (qoder-cn, zcode, …).

But ~/.teamai/debug.log proves these are teamai's own deliveries, e.g.:

2026-11-03T01:41:58Z Synced skill agentkit-multimedia-shopping → copilot
2026-11-03T16:29:51Z Synced skill chrome-automation → dsh / workbuddy / opencode / … (13 tools)
2026-11-05T10:54:13Z Synced skill chrome-automation → zcode

Once the per-tool delivery record is lost, ownership detection fails closed: pull keeps stale copies, refuses to deliver updates, and doctor's advice ("rename or delete it, then run teamai pull") means hand-editing 67 directories. A plain pull can't even retry — doctor notes "a plain pull skips a scope whose team repo has not changed", so recovery needs pull --force.

User-visible effect: deletions recorded in the team repo (via the skills/.removed ledger + PR) do propagate, but any tool dir holding a stale copy whose record was lost keeps it — which reads as "I deleted it and it came back". This took two maintainers on my side a whole session to diagnose, mostly because the owning evidence lives only in debug.log.

Suggestion: make ownership judgment not depend on a fragile per-tool delivery record (e.g. content-hash against the team repo revision), or ship a teamai doctor --rebuild-ledger style command that reconstructs records from the local clone.

Problem 2: write surface ≠ trigger surface, and no per-tool exclusion

The docs ("Which tools actually get hooks") are clear that only some hosts are hook targets. But file fan-out writes into all detected tool dirs regardless. After I uninstalled every hook, teamai doctor shows hooks missing in all 9 hook-target settings — yet skills delivery checks still list every tool as a fan-out target and syncs continue.

config.yaml offers excludedSkills (per-skill) but no per-tool exclusion. There is no supported way to say "sync to workbuddy but never write ~/.zcode". Given ZCode and several other targets only ever receive files passively, a per-tool opt-out (or at least an "inventory only" mode) would prevent most of the surprise.

Related auditability gap: the hook that actually triggered syncs on this machine was registered by an AI-assisted setup session, and it did not land in the documented user-level hooks config (the user-level hooks arrays in the tool's settings are empty). I only found the trigger by reading debug.log's [hook-dispatch] lines. A teamai hooks list that shows not just "which settings file was checked" but "which file currently dispatches" would make install/uninstall auditable.

Problem 3: no secret screening on push/pull — credentials silently fanned out to 13 tool dirs

Skills containing real tokens/API keys (created/imported in opencode and ZCode sessions on my machine) were pushed to the team repo and delivered to all 13 tool dirs with no warning at any stage. I only noticed during an unrelated audit, and cleaned up via two removal PRs (one skill + four skills). Even a local-only regex pass on SKILL.md/references/*.md at push time (high-entropy strings, token|secret|api[_-]?key assignments) with a confirm prompt would have caught this.

Problem 4 [minor]

  • ~/.teamai/debug.log timestamps are bare UTC with no timezone marker. Mixing them with local-clock observations (UTC+8 here) caused a real misdiagnosis (filtering by local hour matched the wrong day entirely). Please log with an offset or document the convention prominently.
  • teamai doctor emits 32 KB+ per run, largely from repeating the same "Kept … it is not teamai's" paragraph 67 times. Collapsing to one line + a count would make it much easier to triage.

What I did as first aid (in case it's useful)

  • Removed the 5 affected skills from the team repo via PRs; verified origin/main file counts are 0 and skills/.removed has the 5 entries
  • Uninstalled teamai hooks from all tools; ~/.codebuddy removed entirely
  • Still pending on my side: the 67 "member's" files under the affected tool dirs (waiting for your guidance on the clean way to re-own them — pull --force after deleting? renaming?)
Dominant language
TypeScript
Stars
5.8k
Forks
500
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.