Problem
In any codeassembly session whose working directory is a subdirectory, every submitted prompt logs a non-blocking hook error:
/bin/sh: .claude/hooks/on-input-received.sh: No such file or directory (exit 127)
The UserPromptSubmit and Notification hooks in .claude/settings.json invoke their scripts by a cwd-relative path. Claude Code runs hook commands in the session's current directory, so any non-root cwd fails to resolve the path, and the errors flood the Claude logs and chat history.
Context
Both hooks exist only to append input_received / waiting_for_input events to an orchestrated run's run-log.jsonl, feeding the factory visualization. That visualization has been dormant for months, and the hooks are codeassembly-repo-local, so they never fire for orchestration in any other repo. The instrumentation currently produces only noise.
The breadcrumb the hooks read (.claude/tmp/active-run-dir) has a second, independent consumer: resolve-frontmatter.sh reads it to stamp run_id on artifact frontmatter. It is not hook-owned.
Proposed solution
Remove the hooks rather than repair the path. The feature they serve is dormant, so fixing the path invests in dead instrumentation; the approach can be reconsidered when the visualization is revived.
Delete both hook blocks and both scripts. Preserve the breadcrumb mechanism and the visualization's dormant read-side (the run-core event schema and folding, the factory demo recording): that machinery is inert, produces no noise, and is still needed to parse historical run logs. Re-anchor the orchestrate/SKILL.md breadcrumb rationale, which currently cites the hooks, onto its remaining consumer (run_id resolution).
Acceptance criteria
Must have
Problem
In any codeassembly session whose working directory is a subdirectory, every submitted prompt logs a non-blocking hook error:
The
UserPromptSubmitandNotificationhooks in.claude/settings.jsoninvoke their scripts by a cwd-relative path. Claude Code runs hook commands in the session's current directory, so any non-root cwd fails to resolve the path, and the errors flood the Claude logs and chat history.Context
Both hooks exist only to append
input_received/waiting_for_inputevents to an orchestrated run'srun-log.jsonl, feeding the factory visualization. That visualization has been dormant for months, and the hooks are codeassembly-repo-local, so they never fire for orchestration in any other repo. The instrumentation currently produces only noise.The breadcrumb the hooks read (
.claude/tmp/active-run-dir) has a second, independent consumer:resolve-frontmatter.shreads it to stamprun_idon artifact frontmatter. It is not hook-owned.Proposed solution
Remove the hooks rather than repair the path. The feature they serve is dormant, so fixing the path invests in dead instrumentation; the approach can be reconsidered when the visualization is revived.
Delete both hook blocks and both scripts. Preserve the breadcrumb mechanism and the visualization's dormant read-side (the
run-coreevent schema and folding, the factory demo recording): that machinery is inert, produces no noise, and is still needed to parse historical run logs. Re-anchor theorchestrate/SKILL.mdbreadcrumb rationale, which currently cites the hooks, onto its remaining consumer (run_idresolution).Acceptance criteria
Must have
.claude/settings.json, and both hook scripts plus the emptied.claude/hooks/directory are deleted.resolve-frontmatter.shconsumer remain intact;run_idfrontmatter resolution is unaffected.orchestrate/SKILL.mdno longer justifies the breadcrumb by the removed hooks.