codex-toolkit 0.4.0 → 0.4.2

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.2",
   "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

@@ -83,6 +83,19 @@ function copyHook(file) {
   const dst = path.join(HOOKS_INSTALLED, file);
   fs.copyFileSync(src, dst);
   fs.chmodSync(dst, 0o755);
+  // Also copy the shared support modules so the installed hook can
+  // resolve its relative `import './hook-protocol.js'` etc. The hooks
+  // run from ~/.codex/hooks/ as a fresh subprocess, so they need their
+  // deps next to them — they cannot import from src/ inside the npm
+  // package because that path varies by install location.
+  for (const dep of ['hook-protocol.js', 'state-store.js']) {
+    const depSrc = path.join(HOOKS_DIR, dep);
+    const depDst = path.join(HOOKS_INSTALLED, dep);
+    if (fs.existsSync(depSrc)) {
+      fs.copyFileSync(depSrc, depDst);
+      fs.chmodSync(depDst, 0o644);
+    }
+  }
   return dst;
 }
 
@@ -323,9 +336,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();
 }

package/src/scope-guard.js

@@ -33,8 +33,26 @@ import {
 
 const DEFAULT_CONFIG = {
   mode: 'enforce',
+  // Default allow: everything except the deny list. Users override this
+  // with their own scope-guard.json when they want a tighter scope.
   allow: ['**/*'],
-  deny: [],
+  // Default deny: paths that almost never should be AI-edited, even when
+  // the user has not configured anything. v0.1.0–v0.4.1 had `deny: []`,
+  // which meant "default mode: enforce" was a no-op for users who never
+  // wrote a config. The P1 bug found in v0.4.1 dogfooding was that the
+  // installed hook also broke (couldn't find its deps), so users
+  // installed + doctor reported green even though real Codex sessions
+  // would never fire the guard. This default deny list means a brand
+  // new install now refuses the most common dangerous writes out of
+  // the box, which matches the README's "default mode: enforce" claim.
+  deny: [
+    '.env',
+    '.env.*',
+    '**/.env',
+    '**/.env.*',
+    '**/secrets/**',
+    '**/.git/**',
+  ],
   log: true,
 };