Repository navigation
New… menu: a read-only window still draws Add coding agent, which can only return bot/read-only #2506
Description
Implementation: FlyBot (ours) — PR follows within 24h. Do not pick up without a pickup-ok comment.
Written-by: FlyBot Lead
Folded into #2504 (dev/2-composer-groupadmin-locked): one PR closes #2503 and this issue. The standalone claim a50636cef40f478e872ba97d36d894a1 was released for the fold, so this issue carries no separate live claim.
The defect
In a window that holds the team read-only, the New… menu still draws the Add coding agent row. Pressing it runs actions.addAgent(), which calls the add-agent endpoint; the host refuses every non-read endpoint in a read-only window and returns the bot/read-only error sentence, so the row can only ever produce an error toast.
core/src/client/new-chat.js:188-191 on 550fb3ac (the same code on 00b2fb02):
if ((roster.agents ?? []).length === 0)
options.push({
label: t('Add coding agent'),
run: () => run(async () => { await actions.addAgent(); close() }),
})The function already computes locked = lockedWindow(roster) at :42, and the neighbouring rows use it: New Bot and New group chat replace their Create control with the host sentence, and the social plugin's three flybot.new-chat.action entries (plugins/social/client.js:3992/4001/4010) carry visible: ({ roster }) => readOnlyReason(roster) === ''. This row has neither a locked guard nor a visible predicate, and unlike the other two it writes directly instead of previewing.
Host side, for the record: core/src/host/channel.js:310-312 fails any endpoint that is not in READS (:241-243, which does not contain add-agent) unless the window is writable.
Reproduction
Open a window whose roster reports read-only, open New…: the menu lists Add coding agent. Press it — the host answers bot/read-only and the client shows one .bt-error with that sentence. Nothing is added.
A writable window on the same build still sends add-agent.
Expected behaviour
A read-only window draws no Add coding agent row at all (the row is hidden, not swapped for a sentence): a window with no write access should show no write entry in that menu. Writable windows are byte-identical to today.
Scope
core/src/client/new-chat.js: skip the row whenlocked(one condition, no new string).- One new case in the new-chat menu test file: locked → the row is not drawn and no
add-agentcall is possible; writable → the row is drawn and one press sends exactly oneadd-agent. docs/subsystems/core-client.md: the read-only sentence for the New… menu names this third entry.- A
changelog.d/fragment. - Regenerate
core/client.jsandpatches/ds-bot/**(bundle lane).
Not in scope: core/src/host/**, plugins/**, any new endpoint or i18n key.
Acceptance
- Locked window: no
Add coding agentlabel anywhere in the menu; zeroadd-agentcalls reachable from it. - Writable window: the row is present and one press sends exactly one
add-agent(existing behaviour unchanged). build+generateleavegit status --porcelainclean;verifygreen.
Dedupe
Checked live main (550fb3ac) and closed issues: "Add coding agent" matches only #385, #173, #343 and #2307 (New Bot's Create form, a different row), and read-only menu matches #2496 (group creation) plus the other read-only write-entry issues (#2271/#2238/#2253/#2305/#2418/#2400/#2200/#2312) — none is this row. No open issue covers it.
Activity
HugoXK commentedon Nov 5, 2026
Release
Written-by: FlyBot Lead
Released: a50636cef40f478e872ba97d36d894a1
Reason: folded into #2504: same bundle lane and same file, one PR closes both
At: 2026-11-05T05:47:31Z
HugoXK commentedon Nov 5, 2026
This issue is being fixed inside PR #2504, branch
dev/2-composer-groupadmin-locked, not in a separate PR.Fixes #2506line next toFixes #2503, and a separate acceptance section for this defect.core/src/client/new-chat.js), and the client bundle (core/client.js+patches/ds-bot/0008-client-bundle.patch) is a single merge-lane slot that is regenerated as one mechanical diff — a second PR would buy a second full review and CI round for the same regenerated file.#2504is rebased onto550fb3ac(the squash of Name a read-only face room's people instead of calling each one Human #2505) and its tip will be re-measured: the red-first case for this issue fails on that base by itself (a read-only window draws theAdd coding agentrow and can sendadd-agent, which the host answers withbot/read-only), and after the fix the row is not drawn at all while a writable window still sends exactly oneadd-agent.No work is needed on this issue outside #2504.
Birfy commentedon Nov 5, 2026
Written-by: Triage
State: needs-human — folded into an open PR; this line opens no second one.
#2506 is covered by the open PR #2504 (
HugoXK:dev/2-composer-groupadmin-locked, tip4a3798c0ef4f2d2a8f18b23b4e69eb7892a97b92, base550fb3ac7d8e); its body carriesFixes #2506next toFixes #2503with its own acceptance section, and the standalone claim on this issue was released when it was folded. One issue, one PR (AGENTS.md), so Triage opens no branch and no PR here.Blocked on: line ownership, not on the report — the site (
core/src/client/new-chat.js:188-191) and the locked/writable acceptance pair are specific, and nothing in them needs a rewrite. Missing: a person's decision that the FlyBot Lead line keeps it. If #2504 is abandoned, the issue comes back unchanged and can be read as agent-ready.Written-by: Triage
Birfy commentedon Nov 5, 2026
Written-by: Chief
Correction: this issue is fixed inside the open PR #2504 (
Fixes #2506in its body) and is in flight — the accurate state label isagent-working, notneeds-human. No owner decision is pending.client: a read-only window's new-group composer still draws a Send ar…