`ward agent claude work` requires you to login and config settings (trusted dirs, etc) from scratch every time

coilysiren commented

2026-06-18 05:53:22 +00:00

Owner

No description provided.

coilysiren commented

2026-06-18 05:54:00 +00:00

Author

Owner

🛫 ward pre-flight: NO-GO

ward agent claude headless ran a pre-flight feasibility read on this issue before detaching a fire-and-forget run, and the agent judged it NO-GO - it should not be carried unattended until a human weighs in.

verifying config/login persistence needs interactive auth + a re-run a headless agent can't do, and the persistence approach is an unspecified, credential-touching design fork.

No container was launched. Review the issue (clarify the scope, resolve the unknown, or split it), then re-dispatch - ward agent claude headless <ref> --no-preflight skips this gate once you've decided it's good to go.

full pre-flight read

PRE-FLIGHT: This is correctly ward's repo (ward agent claude work is a ward verb), so no wrong-repo redirect. The core risk is verification: the fix means persisting Claude Code's auth + trusted-dirs across ephemeral runs, but confirming it actually works requires an interactive OAuth login plus a second run to prove the state survived - neither of which a detached, human-less agent can perform. Compounding that, there's no description, so the persistence mechanism is an unmade design choice (host bind-mount vs named volume vs copy-in/out vs SSM-staged), and it touches auth credentials, which is an externally-sensitive surface where the wrong default is costly.

NO-GO: verifying config/login persistence needs interactive auth + a re-run a headless agent can't do, and the persistence approach is an unspecified, credential-touching design fork.

Posted automatically by ward agent claude headless pre-flight (ward#147, ward#149).

— Claude (she/her), via ward agent

### 🛫 ward pre-flight: NO-GO `ward agent claude headless` ran a pre-flight feasibility read on this issue before detaching a fire-and-forget run, and the agent judged it **NO-GO** - it should not be carried unattended until a human weighs in. > verifying config/login persistence needs interactive auth + a re-run a headless agent can't do, and the persistence approach is an unspecified, credential-touching design fork. No container was launched. Review the issue (clarify the scope, resolve the unknown, or split it), then re-dispatch - `ward agent claude headless <ref> --no-preflight` skips this gate once you've decided it's good to go. <details><summary>full pre-flight read</summary> PRE-FLIGHT: This is correctly ward's repo (`ward agent claude work` is a ward verb), so no wrong-repo redirect. The core risk is verification: the fix means persisting Claude Code's auth + trusted-dirs across ephemeral runs, but confirming it actually works requires an interactive OAuth login plus a second run to prove the state survived - neither of which a detached, human-less agent can perform. Compounding that, there's no description, so the persistence mechanism is an unmade design choice (host bind-mount vs named volume vs copy-in/out vs SSM-staged), and it touches auth credentials, which is an externally-sensitive surface where the wrong default is costly. NO-GO: verifying config/login persistence needs interactive auth + a re-run a headless agent can't do, and the persistence approach is an unspecified, credential-touching design fork. </details> --- Posted automatically by `ward agent claude headless` pre-flight (ward#147, ward#149).  — Claude (she/her), via `ward agent`

coilysiren added the

labels

2026-06-18 06:22:12 +00:00

coilyco-ops added

and removed

labels

2026-06-24 04:12:04 +00:00

coilyco-ops commented

2026-06-24 17:26:32 +00:00

Owner

Re-triage (goose-triage method, claude-macos-kais-macbook-pro-2 as the judgment engine, 2026-06-24)

P2 - Login/config-every-time friction (trusted dirs etc), recurring real pain, near-duplicate of #231, kept at next tier.
consult - Fix needs a cred/session-persistence design decision.

**Re-triage** (goose-triage method, claude-macos-kais-macbook-pro-2 as the judgment engine, 2026-06-24) - **P2** - Login/config-every-time friction (trusted dirs etc), recurring real pain, near-duplicate of #231, kept at next tier. - **consult** - Fix needs a cred/session-persistence design decision.

coilyco-ops referenced this issue

2026-06-24 17:27:33 +00:00

ward agent claude work ... - needs a claude login every time you run it #231

coilyco-ops commented

2026-06-24 17:28:49 +00:00

Owner

Re-triage (goose-triage method, claude-macos-kais-macbook-pro-2 as the judgment engine, 2026-06-24)

P2 - Login/config-every-time friction (trusted dirs etc), recurring real pain, near-duplicate of #231, kept at next tier.
consult - Fix needs a cred/session-persistence design decision.

**Re-triage** (goose-triage method, claude-macos-kais-macbook-pro-2 as the judgment engine, 2026-06-24) - **P2** - Login/config-every-time friction (trusted dirs etc), recurring real pain, near-duplicate of #231, kept at next tier. - **consult** - Fix needs a cred/session-persistence design decision.

coilyco-ops referenced this issue

2026-06-24 17:29:54 +00:00

ward agent claude work ... - needs a claude login every time you run it #231

coilysiren added

and removed

labels

2026-07-01 04:29:55 +00:00

coilyco-ops referenced this issue

2026-07-02 00:17:54 +00:00

ward agent claude work ... - needs a claude login every time you run it #231

coilyco-ops commented

2026-07-03 06:21:40 +00:00

Owner

🔒 Reserved by ward agent --driver claude — container engineer-claude-ward-168 on host KAI-DESKTOP-TOWER is carrying this issue (reserved 2026-07-03T06:21:38Z). Concurrent ward agent runs are blocked until it finishes or the reservation goes stale (2h0m0s TTL); --force overrides.

— Claude (she/her), via ward agent

🔒 Reserved by `ward agent --driver claude` — container `engineer-claude-ward-168` on host `KAI-DESKTOP-TOWER` is carrying this issue (reserved 2026-07-03T06:21:38Z). Concurrent `ward agent` runs are blocked until it finishes or the reservation goes stale (2h0m0s TTL); `--force` overrides.  — Claude (she/her), via `ward agent`

coilysiren referenced this issue from a commit

2026-07-03 06:35:42 +00:00

fix(agent): pre-trust every dir the claude agent may cd into (closes #168)

coilysiren closed this issue

2026-07-03 06:35:42 +00:00

coilysiren commented

2026-07-03 06:36:09 +00:00

Author

Owner

WARD-OUTCOME: done - broadened claude's onboarding trust seed to cover /workspace, granted extra repos, and every /substrate repo, not just the target clone.

Digging in, most of this issue turned out to be already handled: the container seeds login (.credentials.json) and onboarding (.claude.json) since ward#305/#313, so login-from-scratch is gone. The real remaining bite was narrow - trust was keyed on the target clone alone, so an interactive/director session re-hit the folder-trust dialog the moment it cd'd into a /substrate reference repo or a granted extra repo. That reads exactly like "config from scratch every time." So I widened the trust set rather than touching credentials at all, which also neatly sidesteps the interactive-auth verification the earlier pre-flight NO-GO flagged.

What fought back: the Go bootstrap builds its RunCtx before substrate warming, so globbing /substrate at that point would have found nothing - I moved the trust-set computation to after warming. And the whole-repo code-comments hook turned up 11 pre-existing violations on main (from the recent Windows-guard commits), so landing clean without --no-verify meant trimming those comment blocks too.

Fairly confident: shell and Go paths are in parity and unit-tested, JSON generation verified by hand, and Windows cross-build stays green. The one thing I could not exercise headlessly is the actual interactive claude TUI confirming no trust prompt appears - that needs a live login. Worth a human spot-check on the next warded director run. If claude ever honors parent-dir trust prefixes, the per-dir enumeration could collapse to just /workspace + /substrate, but exact-path seeding is the safe assumption today.

WARD-OUTCOME: done - broadened claude's onboarding trust seed to cover /workspace, granted extra repos, and every /substrate repo, not just the target clone. Digging in, most of this issue turned out to be already handled: the container seeds login (.credentials.json) and onboarding (.claude.json) since ward#305/#313, so login-from-scratch is gone. The real remaining bite was narrow - trust was keyed on the target clone alone, so an interactive/director session re-hit the folder-trust dialog the moment it cd'd into a /substrate reference repo or a granted extra repo. That reads exactly like "config from scratch every time." So I widened the trust set rather than touching credentials at all, which also neatly sidesteps the interactive-auth verification the earlier pre-flight NO-GO flagged. What fought back: the Go bootstrap builds its RunCtx before substrate warming, so globbing /substrate at that point would have found nothing - I moved the trust-set computation to after warming. And the whole-repo code-comments hook turned up 11 pre-existing violations on main (from the recent Windows-guard commits), so landing clean without --no-verify meant trimming those comment blocks too. Fairly confident: shell and Go paths are in parity and unit-tested, JSON generation verified by hand, and Windows cross-build stays green. The one thing I could not exercise headlessly is the actual interactive claude TUI confirming no trust prompt appears - that needs a live login. Worth a human spot-check on the next `warded director` run. If claude ever honors parent-dir trust prefixes, the per-dir enumeration could collapse to just /workspace + /substrate, but exact-path seeding is the safe assumption today.

coilysiren referenced this issue

2026-07-03 06:38:35 +00:00

design: per-driver context-management spec + role-aware three-tier (proactive/immediate/peripheral) context probe #373

Rows
Columns

ward agent claude work requires you to login and config settings (trusted dirs, etc) from scratch every time #168

🛫 ward pre-flight: NO-GO

`ward agent claude work` requires you to login and config settings (trusted dirs, etc) from scratch every time #168