[bug] WorkBuddy 5.7.6 的配置已迁移到 ~/.workbuddy-ai(且 hooks 为 Codex 风格),teamai 写入 ~/.workbuddy 的 hooks 永远不会被执行

环境

teamai-cli: 0.27.0(检查过 0.28.0-beta.8,仍按 .workbuddy 旧目录集成)
WorkBuddy(桌面应用): 5.7.6 / build 3e43260f771393d75c6504db99e751eb03dea8db,Windows 11 Pro,Node v24.21.0
scope: user,enabledAgents 含 workbuddy

现象

teamai 对 workbuddy 的所有自检都是绿的(含: Skills delivered to workbuddy、teamai hooks in workbuddy settings、Team instructions are current for workbuddy),但实际 WorkBuddy 会话从未收到 teamai 注入,也从未列出团队技能。

证据 1:hooks 写到了应用不再读取的目录

teamai 0.27.0 把 workbuddy hooks 以 Claude 格式(事件名 SessionStart/Stop/PostToolUse)写入 ~/.workbuddy/settings.json:

{"hooks": {"SessionStart": [{"matcher": "*",
  "hooks": [{"type": "command", "command": "PATH=\"$HOME/.teamai/bin:$PATH\" teamai hook-dispatch session-start --tool workbuddy 2>/dev/null || true", "timeout": 15}]}]}}

但 WorkBuddy 5.7.6 的实际运行数据在 ~/.workbuddy-ai/(该目录含 settings.json、plugins/、sessions/、skills/、security/ 等,settings.json 顶层 keys 为 sandbox/claw/enabledPlugins/...,没有 hooks)。~/.workbuddy/ 已是旧目录残留(仅剩 logs、settings.json、skills)。

证据 2:WorkBuddy 5.7.6 的 hook 体系是 Codex/Cursor 风格,与 Claude 格式不兼容

WorkBuddy 自带的 ~/.workbuddy-ai/skills/create-hook/SKILL.md 显示它的 hooks 为小写事件(sessionStart、beforeShellExecution、preToolUse...)、写入 hooks.json 文件,位置约定为 project .cursor/hooks.json / user ~/.cursor/hooks.json。teamai 写入的 camelCase SessionStart + settings.json 组合既不匹配格式也不匹配位置,应用侧永远不会执行。

证据 3:debug.log 里 workbuddy 的 dispatch 数为 0

~/.teamai/debug.log 中全部 session-start/<tool> hook-dispatch 记录统计:

{'claude': 8, 'codex': 10, 'hermes': 4, 'workbuddy': 2}

仅有的 2 条 workbuddy 记录是我在终端手动执行 teamai hook-dispatch session-start --tool workbuddy 产生的(模拟运行全部 handler ok)。也就是说 teamai 这一端注入逻辑正常,应用侧从未调用。codex/claude/hermes 的 hooks 在同一台机器上均真实执行过。

佐证(源码注释)

dist/index.js 注释仍假设旧布局,且 WorkBuddy 实际以内置插件形式加载 hooks(插件带 hooks/hooks.json,如 ~/.workbuddy-ai/plugins/cache/workbuddy-builtin/sheetagent/.../hooks/hooks.json):

// WorkBuddy runs CodeBuddy's engine: ... Its install probe stays .workbuddy
// (`isToolInstalledForConfig`), whatever directory its rules land in.

期望行为

teamai 探测 WorkBuddy 5.7+ 的 ~/.workbuddy-ai 目录,abilities / 版本检测区分两代 WorkBuddy
new-WorkBuddy 的 hooks 以 Codex 风格(sessionStart 小写事件、hooks.json)写入应用真正读取的位置(或经其插件机制注入)
teamai doctor 对 writing-count≠app-actual-dispatch 的情况给出失败报告,而不是全绿(可与 [feat] One descriptor per tool, and one resolver for where teamai writes and where the tool reads #1221 "one descriptor per tool" 一并考虑)

复现步骤

Windows 11,WorkBuddy 5.7.6 已登录
npm i -g teamai-cli@0.27.0 → teamai init(user scope,含 workbuddy)→ teamai pull
teamai doctor 全绿 ✔
新开 WorkBuddy 会话,询问"你现在有哪些 teamai 团队技能?" → 无任何注入;debug.log 无 workbuddy dispatch 记录

This was generated by AI during triage.

Thanks for the detailed report. This is new: no open issue or PR covers it, and no tag or main has a fix. #1221 is the umbrella for "doctor passes, but the tool never reads the file", but it defers hooks and has no WorkBuddy home item.

What we confirmed. We ran the real CLI on v0.27.0 and on main (d60e68f5), each in a clean HOME with teamai init, teamai pull and teamai doctor:

Hooks go to ~/.workbuddy/settings.json in Claude format (SessionStart, Stop, PostToolUse, UserPromptSubmit). Nothing is written under ~/.workbuddy-ai. v0.28.0-beta.8 has the same paths (checked in source, not run).
teamai doctor exits 0. Every WorkBuddy check resolves to ~/.workbuddy, and the hooks check only looks for teamai's own entries in that file, so a write to a directory the app no longer reads still passes.
With only ~/.workbuddy-ai present, teamai writes no WorkBuddy hooks and doctor fails "workbuddy is installed". The install probe (src/resources/base.ts, INSTALL_ROOTS) and the hook install gate (src/hooks.ts:3165-3169) both key on ~/.workbuddy.

What we could not confirm. We have no WorkBuddy 5.7.6 or Windows 11 here, so the move to ~/.workbuddy-ai and the lowercase hooks.json format are your evidence, not ours. On the debug.log count: teamai logs a dispatch line only when the command reaches teamai. On Windows the hook command is POSIX and relies on the MSYS sh that teamai looks for in WorkBuddy's bundled PortableGit under ~/.workbuddy/binaries/. So a count of 0 fits "the app never calls the hook", and it also fits "the app calls it but the shell never starts teamai". The check below separates the two.

Scope. The same ~/.workbuddy root also holds the skills, agents, MCP config, user rules and the bundled runtime teamai uses. Moving only the hooks would leave the rest on the old home. A fix also has to keep machines that still have only ~/.workbuddy working until we know which WorkBuddy builds read which directory.

Could you run this on 5.7.6?

Find where 5.7.6 loads hooks from. The create-hook skill and the plugin hooks/hooks.json you found are good starting points.
Add a hook there whose only job is to create a file, for example ~/sentinel.txt. It should not call teamai.
Start a new session and check whether the file appears. Tell us the path and the hook format that worked.
Put a skill in ~/.workbuddy-ai/skills and check whether a new session lists it.

If no sentinel runs from any file location, the fix needs another route, such as plugin injection. Labelled question until that run comes back. Once it does, we will mark it bug.

Ran the requested experiments on WorkBuddy 5.7.6 (Windows 11, teamai-cli 0.27.0). Results for steps 1-3:

No candidate location fires. We instrumented three plausible locations, each with a sentinel hook whose only job is to write a distinct marker file (bash.exe -c "echo sentinel-ok > ~/sentinel-X.txt", no teamai, absolute shell path):

~/.workbuddy-ai/hooks.json — Codex style (version: 1, lowercase sessionStart / stop, [{command, timeout}]) — this is the format the app's bundled create-hook skill documents.
~/.workbuddy-ai/settings.json — Claude format, hooks key with SessionStart (app settings backed up first).
~/.cursor/hooks.json — user hooks as named by the bundled create-hook skill, merged as one extra sessionStart entry (teamai's own entries untouched).

The app was fully restarted and a fresh session created. None of the three markers appeared.

The wizard route did not materialize on disk either. We asked the assistant to create a sessionStart user hook via its own create-hook flow writing sentinel-wizard.txt. After restart: no marker file, and no hooks.json/hook script containing the command exists anywhere under ~/.workbuddy-ai, the workspace root, or ~/.cursor/~/.codex. The app's sqlite (workbuddy.db) holds no hook/hooks.json/hook-dispatch strings either. Either the wizard stores hooks inside its encrypted per-user vault (~/.workbuddy-ai/security/<user>/data), which we could not decrypt, or the run did not complete — so we cannot give you the authoritative path; the wizard output was not a hooks.json path on disk in our test.

New evidence on the shell gate: ~/.workbuddy/binaries/PortableGit does not exist on this install; the bundled runtime moved to ~/.workbuddy-ai/binaries/PortableGit/versions/1.3.0 (plus node/, python/). The hook install gate keying on ~/.workbuddy therefore also mis-resolves the sh it needs.

Also confirmed this install: per-workspace app data dirs (<workspace>/.workbuddy-ai/, only memory/ inside), app data ~/.workbuddy-ai/ (settings.json top-level keys: sandbox/claw/enabledPlugins/office*/skillOverrides, no hook config), and the plugin-form hooks (plugins/cache/workbuddy-builtin/*/{.codebuddy-plugin/plugin.json, hooks/hooks.json}).

Upstream round-trip plan unchanged:
afterwards, teamai hook-dispatch session-start --tool workbuddy runs fine manually (all handlers ok), so if the app can be made to execute that command at all, delivery works. If filesystem hook injection is not possible on 5.7.x, the plugin route (injecting a hooks/hooks.json via a configured plugin, which the app demonstrably loads) looks like the only hook surface left.

One more clue for your schema work: 5.7.6 keeps per-workspace app dirs — so the tool descriptor family (#1221) will likely need a workspace-relative variable, not just ~/.workbuddy-ai.

Step 4 (skill listing via the app UI) is still in progress on our side; we will follow up on this issue when we have it.

@XiaoWanWH

Claiming this — it's the exact integration domain I've been working in (#1115, #1215, and the reconcile line). Plan, phased:

Phase 1 (this PR):

Generation-aware probe: .workbuddy-ai/ present ⇒ new generation (5.7+), .workbuddy/ only ⇒ old, so existing installs keep their layout.
New-generation toolPaths: skills/agents under .workbuddy-ai/, and hooks through the Codex-style writer (camelCase event names, hooks.json) instead of the Claude-style settings.json entry.
doctor keeps reporting both generations truthfully (the writing≠dispatch finding the issue asks for aligns with [feat] One descriptor per tool, and one resolver for where teamai writes and where the tool reads #1221 — I'll leave that half to that track per the issue's own note).

Three questions before I build the writer (the code follows the answers):

In 5.7.6, does the app read a user-level ~/.workbuddy-ai/hooks.json at all, or are hooks loadable only inside a plugin's hooks/hooks.json (the create-hook SKILL.md suggests the plugin path)? If plugin-only, injection needs the plugin mechanism, which changes the design.
The exact event vocabulary: is it sessionStart / preToolUse / beforeShellExecution / … — and does it include the events teamai needs (session-start, stop, post-tool-use, prompt-submit equivalents)? A pointer to the app's hook schema (or a paste of the SKILL.md's list) pins the mapping.
Does new-generation WorkBuddy still read Claude-style settings.json hooks at all (dual-reader compatibility), or is the old format fully dead?

I'll build the probe + toolPaths half now — it's independent of the answers — and hold the writer until they land. Happy to verify against a real 5.7.6 setup if you can run a check build (@XiaoWanWH your evidence trail suggests you have the live app).

@XiaoWanWH

This was generated by AI during triage.

Thanks @XiaoWanWH, that settles the main question. A sentinel that does not call teamai never fired from any of the three files, so 5.7.6 does not run user hooks from a file on disk. Your debug.log reading was right.

@kittimzhe, the run answers two of your three questions, and it changes the plan:

Q1 and Q3. Neither ~/.workbuddy-ai/hooks.json (Codex style) nor hooks in ~/.workbuddy-ai/settings.json (Claude style) fired, and ~/.cursor/hooks.json did not either. A writer for any of these would write a file 5.7.6 does not read, so please hold the hooks writer until the plugin route below is confirmed.
Safe to build now. The generation-aware probe, with ~/.workbuddy-only installs left as they are. The bundled runtime moves with it: on this install PortableGit is at ~/.workbuddy-ai/binaries/PortableGit/versions/<v>, and src/bundled-runtime.ts looks for it only under ~/.workbuddy/binaries/. It looks for the bundled Node only under ~/.workbuddy/bundled/node/. The install gate and the sh lookup both have to accept the new home.
Not yet. Skills and agents under ~/.workbuddy-ai/ wait for step 4. The per-workspace <workspace>/.workbuddy-ai/ holds only memory/, so nothing teamai writes goes there yet.

Next check, for the plugin route. @XiaoWanWH, when you have time:

Paste one built-in plugin's .codebuddy-plugin/plugin.json and hooks/hooks.json, redacted as needed. That gives the event names (Q2) and the hook schema plugins use.
Paste the shape of enabledPlugins in ~/.workbuddy-ai/settings.json, keys only.
Copy one built-in plugin to a new plugin with its own name, replace its hooks with a single sessionStart sentinel, add it to enabledPlugins, restart, and check for the marker. If the app only loads plugins from a marketplace, say where it lists marketplaces.

If a user plugin loads, the fix is a teamai-managed plugin with a hooks/hooks.json that calls teamai hook-dispatch. If it does not, WorkBuddy 5.7.6 has no hook surface teamai can use, and only skills and rules can be delivered.

@XiaoWanWH

Answers to your three questions, from live evidence on the 5.7.6 install (warnings where the evidence is asymmetric):

Q1 — does 5.7.6 read a user-level ~/.workbuddy-ai/hooks.json?
No signal that it does. Our sentinel in exactly that file (Codex style) never fired. The wizard route wrote nothing to disk anywhere (previous comment). The only hooks files that ship in this install are plugin-carried: plugins/cache/workbuddy-builtin/*/hooks/hooks.json. So treat it as plugin-only until proven otherwise — i.e., design the writer for the plugin mechanism, and use the sentinel-file probe to confirm each candidate location before relying on it.

One hint pointing the same way: the bundled create-hook SKILL.md itself named .cursor/hooks.json as the "user hooks" location (we sentinel-tested that too — no fire), so the bundled docs do not describe a live 5.7.x surface either.

Q2 — event vocabulary
Verbatim from the bundled create-hook SKILL.md (captured earlier today; note the file has since been rotated out of ~/.workbuddy-ai/skills/ by the app after a restart — built-in skills do not seem to persist on disk):

sessionStart, sessionEnd, preToolUse, postToolUse, postToolUseFailure, subagentStart, subagentStop, beforeShellExecution, afterShellExecution, beforeMCPExecution, afterMCPExecution, beforeReadFile, afterFileEdit, beforeSubmitPrompt, preCompact, stop, afterAgentResponse, afterAgentThought

Mapping teamai needs: sessionStart → session-start, stop → stop, postToolUse → post-tool-use are all present. There is no direct UserPromptSubmit equivalent in that list — closest is beforeSubmitPrompt, but its semantics (pre-submission validation) differ from prompt-submit injection; treat prompt-submit coverage as unproven.

Q3 — does 5.7.6 still read Claude-style settings.json hooks?
Our sentinel (hooks key with SessionStart merged into ~/.workbuddy-ai/settings.json) did not fire. Combined with the old ~/.workbuddy/settings.json being dead here, our evidence says the Claude-format reader is gone in user scope on this build. We can't rule out a migration shim writing into the encrypted per-user vault, but for injection purposes assume it's dead.

And yes to the check build — @XiaoWanWH can run it against this live 5.7.6 (this issue's trail is from this machine). The skill-delivery half is already validated on this install via the toolPaths redirect (12+2 skills land in ~/.workbuddy-ai/skills on every pull), so once the probe code lands we'll re-run doctor/pull natively.

Practical note for the writer: our Phase-1 bridge already survives in production here — redirect + the app's own /hooks-created hook are the user-accepted stopgap, and anything upstream ships should be tested to not double-deliver over a member's manual bridge.

Step 4 result (closing the loop): the 13 team skills delivered via the toolPaths redirect to ~/.workbuddy-ai/skills/ DO show up in the app's skill menu (user pressed / in the live 5.7.6 session: architecture-diagram, github, systematic-debugging, etc. all present, plus one member-published skill).

So on a 5.7.6 install:

skill delivery works with the redirect alone — no plugin, no hook needed; the app scans its own ~/.workbuddy-ai/skills/.
context injection still has no working surface until the hooks writer lands (sentinels + wizard all negative as documented above).

Your Phase-1 probe + toolPaths half covers the first bullet natively; the open dependency is only the plugin-route hooks writer. Sounds like bug now per your own labeling rule.

@kittimzhe

This was generated by AI during triage.

Thanks, this narrows it down.

Skills. Confirmed on 5.7.6: the app lists skills from ~/.workbuddy-ai/skills/. @kittimzhe, skills can go in the first PR along with the probe and the bundled runtime. Agents are still unverified.
Events. sessionStart, stop and postToolUse cover three of teamai's four hooks. With no prompt-submit event, the writer should skip that hook on 5.7.6 instead of mapping it to beforeSubmitPrompt.

One point needs clearing up before the writer is designed. The earlier comment says the hook made through create-hook produced no marker and left nothing on disk. This one says a hook created with the app's /hooks is a working stopgap in production. Are these two different routes? If the /hooks hook does fire, please check whether ~/.teamai/debug.log shows session-start/workbuddy lines from real sessions. If it does, 5.7.6 has a user hook surface after all, stored somewhere we have not found, possibly the vault. That changes the design, and the writer has to avoid double delivery over it.

The plugin check from the previous comment (a built-in plugin.json and hooks/hooks.json, the shape of enabledPlugins, a user plugin with a sentinel) is still the one that decides the writer.

fix(workbuddy): prefer the 5.7+ root on upgraded installs, after user…

Phase 2 (the hooks writer) — to target the real plugin mechanism rather than guess, two probes from your live install would pin the design:

Plugin discovery: the tree under ~/.workbuddy-ai/plugins/ one level past cache/ — how are plugins laid out (one dir per plugin with a manifest? a registry file next to cache/ listing what's enabled?), and does an app restart pick up a manually created directory there, or does installation only go through an in-app flow (marketplace / git URL / file import)?
A minimal hand-made plugin carrying one hook — even just your sessionStart sentinel — dropped wherever sync: v0.16.3 from internal #1 says the app discovers them. If it fires after a restart, the writer can synthesize a teamai plugin carrying our dispatch hooks; if it doesn't, the cache is verified content (hash-checked) and the route needs an install-time integration instead.

If a manual plugin loads, I'll shape the writer as: generate ~/.workbuddy-ai/plugins/teamai/hooks/hooks.json with the camelCase event names mapped to teamai hook-dispatch, plus reconcile/doctor support, and you verify on the live app again — same loop as the skills half.

@XiaoWanWH

Adding one probe to the list so @XiaoWanWH can answer everything in one pass — SaulMoro's point above: if the app's /hooks-created hook is firing in production, does ~/.teamai/debug.log now show session-start/workbuddy lines from real sessions (not the two manual dispatches from the original report)? If yes, 5.7.6 has a user hook surface stored somewhere we haven't found (possibly the vault), and the writer must not double-deliver over it.

feat(install): recognize WorkBuddy 5.7+'s .workbuddy-ai root (Tencent…

feat(skills): deliver WorkBuddy skills to the 5.7+ root (Tencent#1273)

feat(install): recognize WorkBuddy 5.7+'s .workbuddy-ai root (Tencent…

feat(skills): deliver WorkBuddy skills to the 5.7+ root (Tencent#1273)

fix(workbuddy): prefer the 5.7+ root on upgraded installs, after user…

feat(locate): carry the WorkBuddy generation swap into the locate pip…

This was generated by AI during triage.

Status: #1290 (probe plus skills under .workbuddy-ai/) works for skills, but changes are requested. On a 5.7-only member it now also writes rules, MCP and hooks into .workbuddy/, and doctor reports them as delivered. The bundled runtime has not moved yet. The hooks writer is still waiting on the plugin check above.

feat(install): recognize WorkBuddy 5.7+'s .workbuddy-ai root (Tencent…

feat(skills): deliver WorkBuddy skills to the 5.7+ root (Tencent#1273)

fix(workbuddy): prefer the 5.7+ root on upgraded installs, after user…

feat(locate): carry the WorkBuddy generation swap into the locate pip…

fix(workbuddy): fail non-skills surfaces closed on 5.7-only members (T…

fix(doctor): name the surfaces a .workbuddy-ai-only member does not g…

fix(doctor): report held WorkBuddy hooks when no other surface is map…

docs: note what a WorkBuddy member with only .workbuddy-ai gets (Tenc…

feat(workbuddy): recognize the 5.7+ .workbuddy-ai root and deliver sk…

Navigation Menu

Repository navigation

[bug] WorkBuddy 5.7.6 的配置已迁移到 ~/.workbuddy-ai(且 hooks 为 Codex 风格),teamai 写入 ~/.workbuddy 的 hooks 永远不会被执行 #1273

环境

现象

证据 1:hooks 写到了应用不再读取的目录

证据 2:WorkBuddy 5.7.6 的 hook 体系是 Codex/Cursor 风格,与 Claude 格式不兼容

证据 3:debug.log 里 workbuddy 的 dispatch 数为 0

佐证(源码注释)

期望行为

复现步骤

2 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[bug] WorkBuddy 5.7.6 的配置已迁移到 ~/.workbuddy-ai(且 hooks 为 Codex 风格),teamai 写入 ~/.workbuddy 的 hooks 永远不会被执行 #1273

Description

环境

现象

证据 1:hooks 写到了应用不再读取的目录

证据 2:WorkBuddy 5.7.6 的 hook 体系是 Codex/Cursor 风格,与 Claude 格式不兼容

证据 3:debug.log 里 workbuddy 的 dispatch 数为 0

佐证(源码注释)

期望行为

复现步骤

Activity

SaulMoro commented on Oct 22, 2026

XiaoWanWH commented on Oct 22, 2026

kittimzhe commented on Oct 22, 2026

SaulMoro commented on Oct 22, 2026

XiaoWanWH commented on Oct 22, 2026

XiaoWanWH commented on Oct 22, 2026

SaulMoro commented on Oct 22, 2026

kittimzhe commented on Oct 23, 2026

kittimzhe commented on Oct 23, 2026

2 remaining items

SaulMoro commented on Oct 25, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions