[Beehtrix]

Option 1 from #110: document that Qwen Code 0.26.7 and later skip the adapter's hooks until the user approves them or trusts the folder.

@ashtom @suhaanthayyil, you've merged and written most of the Qwen adapter, so I'm tagging you here. In #110 I offered a PR for whichever option you prefer. This is the minimum one (docs), sent now so it's ready to merge. If you'd rather have option 2 (a warning at install) or option 3 (user-level hooks) as well or instead, say so and I'll follow up or close this.

Why

Since Qwen Code 0.26.7, Qwen skips the hooks in a project's .qwen/settings.json until the user allows them. The adapter installs all of its hooks there, so until then no Entire hook runs and the session records nothing: no prompts, no turns, no checkpoint. Qwen only prints a warning. Neither README mentions this, and both usage examples run qwen -p ... --yolo straight after entire enable, which records nothing on current Qwen.

What

• Agent README, new section "Approve The Hooks In Qwen Code": the two ways to allow the hooks (the approval dialog in 0.26.8 and later, or folder trust, which is the only way on 0.26.7), what a headless qwen -p run needs, that Qwen asks again when the hooks or the project's env change, how to undo a rejection, and that the files move under $QWEN_HOME when it is set.
• Both usage examples start with one interactive qwen to approve the hooks.
• Root README Qwen section: a short summary that links to the new section, in the same style as the Grok trust note.
• Development section, and the QWEN_E2E row in the root README: the live lifecycle tests run qwen -p --yolo in new temp repos, so on 0.26.7 and later they need folder trust that covers $TMPDIR.

How Qwen decides (0.26.9 npm bundle)

• Approvals are stored per project root in hookApprovals.json in the global Qwen dir (QWEN_CODE_HOOK_APPROVALS_PATH overrides it). The key is a sha256 of the hooks block plus the project's env (.env files inside the workspace and the env setting). A missing or mismatched entry is pending (LoadedHookApprovals.getState).
• applyProjectHooksApproval: hooks stay pending unless they were approved, or the folder is explicitly trusted and they weren't rejected.
• Explicit trust means security.folderTrust.enabled (or IDE workspace trust) plus a trust rule for the folder. TRUST_FOLDER covers subdirectories, and TRUST_PARENT covers the parent.
• With folder trust on and the folder untrusted, settings drop the project hooks before the approval step, so approving them doesn't help. The dialog's own text says the same.
• --yolo on the command line skips the approval gate. The hooks then run only if they were approved earlier and the hash still matches, or if the folder is explicitly trusted. A headless run without --yolo warns "they are not approved for this folder. Run qwen interactively here to review them"; with --yolo it warns "the folder is not explicitly trusted".

Not in this PR

• Install output. qwen: Qwen Code 0.26.7+ skips the adapter's hooks until the user trusts them #110's option 1 also mentions the install output, but the adapter has no way to reach the user from install-hooks. The protocol's response is just {"hooks_installed": N}, and the CLI's external.Agent.runIn reads stderr only when the subcommand fails, so a notice printed on success never shows up in entire enable. An install-time notice needs a CLI or protocol change, so this PR is docs only.
• The e2e harness. I didn't change it, because trusting its temp repos would mean writing to the developer's real ~/.qwen.

Verification

• Docs only. go build ./... and go test ./... in agents/entire-agent-qwen pass.
• The rules above come from reading the Qwen Code 0.26.9 npm bundle. The trust half matches the live 0.26.9 run in qwen: Qwen Code 0.26.7+ skips the adapter's hooks until the user trusts them #110: a headless --yolo run in an untrusted folder printed the warning and ran no hooks, and once the folder was trusted every hook fired. I didn't run the approval dialog or the non-yolo headless warning live.
• The new anchors match their headings. The branch merges cleanly with fix(qwen): report token usage from Qwen's own chat log #111 (Qwen token usage), which also edits the agent README.

Refs #110

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has insufficient remaining quota.

[chatgpt-codex-connector]

Codex Review Summary: ✅ Completed

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-11-07T02:22:55.612613Z	813231b	PR opened

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.