codex-toolkit 0.4.0 → 0.4.1

package/README.md

@@ -69,10 +69,22 @@ Both points emit a JSON decision `{ "decision": "allow" | "ask" | "deny", "reaso
 ## Install
 
 ```sh
-# Coming soon (not published yet — see "Roadmap"):
-#   npx codex-toolkit init
-#
-# For now, install from this repo:
+# 1. Pull the package (no global install needed):
+npx codex-toolkit@latest init
+```
+
+That one command copies every bundled hook into `~/.codex/hooks/`, writes `~/.codex/hooks.json` registering them with Codex CLI, and appends a `[hooks]` section to `~/.codex/config.toml` (only if you don't already have one).
+
+Verify:
+
+```sh
+npx codex-toolkit@latest list     # see what is installed
+npx codex-toolkit@latest doctor   # run sanity checks + smoke test
+```
+
+If you'd rather install from source (e.g. to hack on a hook), clone the repo and run the same `init` command directly:
+
+```sh
 git clone https://github.com/fox328230966-alt/codex-toolkit.git
 cd codex-toolkit
 node bin/codex-toolkit.js init
@@ -254,7 +266,7 @@ no extra deps). CI runs the suite on Node 18, 20, and 22.
 - [x] `shield-destructive-cmd` — v0.3.0
 - [x] `shield-env-guard` — v0.3.0
 - [x] `auto-lint` — v0.4.0
-- [ ] `npx codex-toolkit init` published to npm — v0.4.0
+- [x] `npx codex-toolkit init` published to npm — v0.4.0
 - [ ] Per-hook "explain why" debug output — v0.5.0
 - [ ] Codex IDE extension parity — v0.6.0
 

package/bin/codex-toolkit.js

@@ -2,5 +2,17 @@
 // codex-toolkit — main CLI shim. Forwards to src/installer.js#main.
 // This file is the `bin` entry; the real implementation lives in src/ so
 // it can be unit-tested without spawning a subprocess.
+//
+// We can't rely on a top-level "am I the entry point?" check inside
+// src/installer.js: when this bin is invoked through `npx codex-toolkit …`,
+// `process.argv[1]` points at the npx launcher, not at this file, so a
+// argv-based check would (and did) silently skip the main() call. Instead
+// we explicitly invoke the entry function from here.
 
-import('../src/installer.js');
+(async () => {
+  const mod = await import('../src/installer.js');
+  mod.main();
+})().catch((err) => {
+  process.stderr.write(`[codex-toolkit] fatal: ${err.stack || err.message}\n`);
+  process.exit(1);
+});

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "codex-toolkit",
-  "version": "0.4.0",
+  "version": "0.4.1",
   "description": "Stop AI scope creep in Codex CLI. A toolkit of practical hooks that keep your AI edits scoped, budgeted, and safe.",
   "type": "module",
   "main": "src/index.js",

package/src/installer.js

@@ -323,9 +323,19 @@ function main() {
   }
 }
 
-const invokedDirectly =
-  import.meta.url === `file://${process.argv[1]}` ||
-  process.argv[1]?.endsWith('codex-toolkit.js');
-if (invokedDirectly) {
+// Export main so bin/codex-toolkit.js can invoke it explicitly. (The
+// previous top-level "am I the entry point?" check was unreliable: when
+// invoked through `npx codex-toolkit …`, process.argv[1] points at the
+// npx launcher, not at this file, so the check silently returned false
+// and the CLI produced no output.)
+export { main };
+
+// Fallback for direct invocation: `node src/installer.js` (used in unit
+// tests and local debugging). When loaded via the bin, the IIFE in
+// bin/codex-toolkit.js handles the call — and we must NOT also fire here,
+// otherwise every command runs twice.
+const __filename = fileURLToPath(import.meta.url);
+const entryPoint = process.argv[1] ? path.resolve(process.argv[1]) : null;
+if (entryPoint && entryPoint === __filename) {
   main();
 }