# Bug / Feature Tracker

- [ ] **Project `path_rules` updates never propagate to the firewall store after first seed (regression introduced by CP firewall ownership).** `BootstrapServicesPreStart` (`internal/cmd/container/shared/container_start.go:153`) calls `FirewallAddRules` with the project's full `EgressRules()` on every agent container start. `addRulesToStore` (`internal/controlplane/firewall/handler.go:1014`) dedups by `RuleKey = dst:proto:port` — same-key collisions are silently dropped (`if exists known[key] continue` at line 1028). Result: any change to `path_rules`, `path_default`, `action`, or any non-key field for an already-stored domain is invisible — only domains never seen before propagate. Hard-confirmed: `.clawker.yaml` had 5 path_rules under `raw.githubusercontent.com:tls:443`; store file (`.clawkerlocal/.local/share/clawker/firewall/egress-rules.yaml`) had 3 (the snapshot from when the rule first landed in an empty store). `clawker container stop` + `clawker controlplane down` + `clawker run` did NOT re-seed because the store file lives in `FirewallDataSubdir` and persists across CP container teardown. Pre-CP (host-side `internal/firewall/Manager` daemon) the bug existed in code but the user-visible symptom was masked — likely because daemon-restart cycles + different volume topology made fresh seeds more frequent. Post-CP (#255) the store is durable on the CP bind-mount volume and the trailing-mutation invariant in `FirewallRemove` (`internal/controlplane/firewall/CLAUDE.md`) explicitly preserves the store across `firewall down/up`, so stale path_rules are now permanent until manual intervention. Fix options: (A) merge `path_rules` (union by `path`, caller wins on `path_default`/`action`) when `addRulesToStore` sees an existing key — yaml is the project source-of-truth; (B) add `FirewallUpsertRule` RPC and switch the bootstrap caller; (C) in `BootstrapServicesPreStart`, do remove+add per project rule (crude — clobbers any operator-added rule for that key). Recommend (A). Workaround: `clawker firewall remove <domain>` then restart agent container (NOT `controlplane restart` — that doesn't trigger `BootstrapServicesPreStart`); or hand-edit the store file then `clawker firewall reload`.
- [x] ~~**Entrypoint timeout is the only abort guard for failed init.**~~ **[resolved by clawkerd-pid1]** Entrypoint + fifo are gone — clawkerd is PID 1 and supervises the spawn directly. When the CP-driven init plan fails, CP simply never dispatches `AgentReady`; clawkerd never spawns the user CMD; on `ctx.Done` (container stop or SIGTERM) clawkerd exits without the 11-minute fifo wait. The bug is resolved by elimination, not by adding an explicit `AbortInit` Command.
- [ ] Clawker firewall up / clawker controlplane up fails if CP image isn't built yet. needs to handle building and starting the cp image along with better helper instructions. Seems to have resolved on a second attempt but should be looked into.
- [ ] clawker project templates (ie golang) giving error, might need node for claude hooks to work: "UserPromptSubmit hook error",  "SessionStart:startup hook error": "Failed with non-blocking status code: /bin/sh: 1: node: not found". we should ensure this is installed on dockefile templates. or there might be an issue with clawkerd unpriv user drop. 
- [ ] Remove all looping features
  
```
clawker firewall up
Error: Image 'clawker-controlplane:latest' not found

Next Steps:
  1. Check the image name and tag are correct
  2. Verify you have network access to the registry
  3. Try pulling manually: docker pull clawker-controlplane:latest
```

- [ ] `clawker controlplane up`/`clawker firewall up` give no status output, no progress spinner. just hangs until a success message. bad ux
- [ ] `clawker firewall up` fails with `✗ starting firewall: rpc error: code = Internal desc = firewall init: firewall stack: envoy: creating container clawker-envoy: Failed to create container: Error response from daemon: invalid mount config for type "bind": bind source path does not exist: /root/.local/share/clawker/firewall/envoy.yaml`
- [ ] Not using `internal/docker` client in `cmd/clawker-cp/main.go`
- [ ] `cmd/clawker-cp/main.go` should probably be a light wrapper around `internal/controlplane` package instead of doing all the work itself.
- [ ] `clawker firewall up` doesn't need to display the stack ip and network id (its not even the name lol its a long random id). its totally useless info to the user.
- [ ] CP should remove its container on shutdown imo. unless there is some functional benefit or constraint in doing so
- [ ] controlplan up doesn't start firewall but should via settings
- [ ] make localenv seems to break mounting on container create ie `clawker run` forcing a `docker run` and mounting the volumes seems to fix it. so something is up with bind mounting during container create, after the container is created. claude has no idea what to do its totally going in circles.
- [ ] `internal/controlplane/agent/init_test.go::TestExecutor_Plan_UidGid_RootForDockerSocket_UserForRest` walks `e.plan()` directly and asserts UID/GID/HOME/USER on un-dispatched stages — pins constants against themselves. Should rewrite to capture the dispatched `*clawkerdv1.Command` payloads off `stream.sent` inside `TestExecutor_Run_HappyPath` and assert the privilege fields on the wire frames, so values flow through `runStep`'s payload construction. Landed as-is in commit `ae5dfd4e`.
- [x] ~~**handleAgentReady write/close failure paths uncovered.**~~ **[resolved by clawkerd-pid1]** Handler no longer touches a fifo; failure modes are spawn-error-shaped (`spawnState.Run` return values: nil / `errAlreadySpawned` / spawn errors) and unit-tested directly via the `spawnEntry` thunk seam.
- [ ] **CP-resilience audit: pre-existing panics on CP-reachable code paths.** Per the resilience contract (no panics in CP — see root `CLAUDE.md` and `internal/controlplane/CLAUDE.md`), the following panics need to be converted to `(nil, error)` returns or recovered. A panic in any of these crashes CP PID 1, skips `Stack.Stop` + `ebpfMgr.FlushAll`, and leaves eBPF programs pinned with no supervisor (silent firewall failure — agents keep filtering against frozen rules with no observation, no rule updates, no containment dispatch). Sites: `internal/controlplane/server.go:50` (`NewAdminServer`), `internal/controlplane/watcher.go:62/65/68` (`NewAgentWatcher`), `internal/controlplane/agent/registry.go:206` (`Add`), `internal/controlplane/firewall/handler.go::NewHandler` (per KEY-CONCEPTS line — panics on missing `EBPF` or `Resolver`). All are constructor-time nil-dep panics — same shape as `agent.NewExecutor` was before being converted; same fix pattern applies. Add tests pinning the error-return contract.
- [ ] Clawker share dir should be overridable via env var and settings
- [ ] Socketbridge deamon log files need to be rotated and cleaned up somehow. It is also difficult to really track down which daemon log is the most recent one visually especially when hundreds of log files are generated. Aggregating logs into a single file with timestamps and log levels would be ideal.
- [ ] Egress monitoring for the firewall stack
- [ ] Might be nice to have all logging also aggregated in monitoring stack  
- [ ] **Monitoring stack hardening pass.** Local-dev stack currently ships with security plugins off, OTLP receiver published on all interfaces, no auth on OpenSearch/Dashboards, no scoping on incoming pushes, and reserved hostnames (`otel-collector`, `prometheus`) resolvable from agent containers behind the firewall (`internal/consts/monitoring.go` `MonitoringServiceHostnames` — OpenSearch + Dashboards are intentionally not forwarded; revisit if that policy changes). Defer until functionality is stable; revisit before any "production" framing.
- [ ] **Transparent TCP for random ports not working** — TLS on non-443, HTTP on non-80 (e.g. `tls://host:4443`, `http://host:8080`) doesn't route through Envoy. Needs Envoy config update. (Migrated from `firewall-egress-stack-e2e-bugs`; may have been addressed by eBPF pivot on `fix/project-egress-priority` — re-verify against current `internal/firewall/envoy.go` before triaging.)
- [ ] **HTTP over raw IP (no domain) never tested** — unclear whether it's even implemented. (Migrated from `firewall-egress-stack-e2e-bugs`; same re-verify note as above.)
- [ ] **Consider wiring CLI logger mTLS.** `internal/cmd/factory/default.go::newLogger` wires `clawker-cli` with `Insecure: true` to the untrusted `otlp` receiver on `OtelGRPCPort`; the file-path triple on `logger.OtelOptions` has no in-tree consumer. NOT a security trust issue — CLI log records carry no repudiation weight; spoofing `service.name=clawker-cli` doesn't compromise the trusted forensic indices (which are scoped to CP/Envoy/CoreDNS via the `otlp/infra` receiver's infra-intermediate `client_ca_file`). Consideration is operational hygiene: anyone with reachability to the collector's public OTLP port can inject `clawker-cli` events. Two paths if revisited: (a) mint a CLI-scoped infra leaf via `otelcerts` and add a `clawker-cli` branch to `routing/trusted` in `otel-config.yaml.tmpl`, or (b) leave on plaintext lane and document as intended. Either way, the dormant file-path triple on `OtelOptions` should be reconciled — delete it, or wire a real consumer.
- [ ] **Loki ingester wedges into permanent "shutting down" state when Docker disk usage limit is hit.** Container stays running and serves queries (existing data still browsable in Grafana), but every push (otelcol → Loki) is rejected with `gRPC err="Ingester is shutting down"` / HTTP 503. CP + otel-collector are healthy; problem is downstream in the monitoring stack. Observed once (2026-04-26, ~17:47 UTC); resolved by `docker restart loki` after freeing Docker disk space. Two follow-ups: (1) review log retention / volume sizing for Loki + otel-collector + per-container clawkerd.log so the disk doesn't fill in normal operation; (2) investigate whether some component is log-spamming (audit `clawkerd.log` rotation defaults, CP's `informer stats heartbeat` cadence at 30s, otel-collector retry storm when Loki is wedged — the retry loop itself can spam its own log since the writes back-pressure but the log isn't gated).
- [ ] Running a container outside of a registered project directory fails with
```
Error: Failed to copy files to container 'bda850fbedc4e9f7dce999fc621a60127da6ea4beed26af3a392ebba25e475b8'
  Details: Error response from daemon: Could not find the file /run/clawker in container bda850fbedc4e9f7dce999fc621a60127da6ea4beed26af3a392ebba25e475b8

Next Steps:
  1. Check if the container exists: docker ps -a
  2. Verify the destination path is valid
  3. Check if the source file exists
```
- [ ] Project init on linux at least fails when selecting typescript preset at least `writing .clawker.yaml: storage: remerge: storage: unmarshalling to struct: yaml: unmarshal errors: line 23: cannot unmarshal !!str `ENV NVM...` into []string` after cloning clawker.dev repo. Seems to be ignoring the existing `.clawker.yaml`. `clawker project register` `✗ no project config found in /home/ubuntu/clawker.dev — run 'clawker project init' first to create one`. Might be a malformed file so its struggling to read it and claiming it doesn't exist instead. Update: confirmed due to legacy field type after_user_switch was multi-line string, now list
- [ ] logs from infra containers on linux are owned by root and unread without sudo
- [ ] when gpg agent was dead the container TTY doesn't fully shutdown nor does it get destroyed it hangs. looks like claude does exist tho
- [ ] clawker needs to remove containers if CP fails. containers should be atomic on any failure period 
