Feature Idea: Web UI for managing and viewing crawls

[greenido]

Description

I would like to suggest adding a web-based user interface to wacrawl to make it easier to manage, configure, and visualize crawls without relying entirely on the command line :) call me crazy... but I like to 'see' things.

To help kickstart this idea or act as a reference, I've put together a companion UI project here:
https://github.com/greenido/wacrawl-ui

How it Helps

• Dashboard: Provides a visual way to monitor ongoing crawl status and history.
• Configuration: Simplifies setting up crawl parameters, targets, and schedules via a clean interface.

[steipete]

I like the idea. It fits the work I do in https://birdclaw.sh - need to find a bit of time to do this right. Also still wonder about a unified story with wacli/wacrawl.

[greenido]

Yes! Absolutely 👍🏽
Happy to help on it as well.

Keep rocking!

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed June 13, 2026, 4:13 PM ET / 20:13 UTC.

Summary
Keep open: current main and v0.2.7 still provide CLI, JSON, sync/search/status, backup, and crawlkit control metadata, but no built-in web dashboard or scheduling/configuration UI. The linked companion UI and local viewer are useful references, while maintainer discussion remains unresolved around Birdclaw, wacli, core scope, and privacy posture.

Reproducibility: not applicable. this is a feature request rather than a bug report. Source review confirms current main has CLI/JSON/control metadata only, with no built-in web UI to reproduce against.

Ways to help us reproduce this

• Add a screenshot or short recording showing the behavior.
• Add expected vs actual behavior.

Next step
Manual review is the right lane because the next step is deciding product scope and security posture, not coding a narrow fix.

Security
Needs attention: The issue is security-sensitive because a local web UI would expose private WhatsApp archive data and needs an explicit access/privacy model.

Review details

Best possible solution:

Define a local-only dashboard/control architecture around the existing JSON and crawlkit metadata surfaces, then decide the core-versus-companion boundary before implementation.

Do we have a high-confidence way to reproduce the issue?

Not applicable; this is a feature request rather than a bug report. Source review confirms current main has CLI/JSON/control metadata only, with no built-in web UI to reproduce against.

Is this the best way to solve the issue?

Unclear; the requested UI may be valuable, but the best implementation path depends on maintainer decisions about core scope, privacy model, scheduling/config persistence, and Birdclaw or wacli integration.

AGENTS.md: not found in the target repository.

Remaining risk / open question:

• A local web UI would expose private WhatsApp archive data, so binding, authentication, media serving, redaction, and local-only access need explicit security design.
• The discussion has not settled whether the dashboard belongs in wacrawl core, Birdclaw, wacli, or a companion project.

Codex review notes: model internal, reasoning high; reviewed against 63b37d8d4f83.

Label changes

Label justifications:

• P3: This is a useful but speculative product feature with no current broken workflow or urgent regression.
• impact:security: A web dashboard would present private WhatsApp archive data, so the issue materially involves sensitive-data exposure boundaries.

Evidence reviewed

Security concerns:

• [medium] Design local web access around private archive data — README.md:121
  A dashboard or scheduler would read message, contact, chat, and media metadata from the local archive, so maintainers should define local-only binding, authentication, media-path handling, and redaction expectations before implementation.
  Confidence: 0.86

What I checked:

• No target AGENTS.md: The target wacrawl checkout does not contain an AGENTS.md file, so no target-specific repository policy applied.
• Current documented surface is CLI/archive/search: README describes wacrawl as a read-only local archive/search CLI with scriptable status, chat listing, message listing, full-text search, and JSON output, not a web UI. (README.md:7, 63b37d8d4f83)
• Sync exists without dashboard scheduling UI: README documents read-time sync modes and staleness behavior but no visual scheduler or configuration dashboard. (README.md:244, 63b37d8d4f83)
• CLI dispatch has no web command: The command switch handles metadata, doctor, import/sync, status, chats, contacts, unread, messages, search, and backup only. (internal/cli/cli.go:90, 63b37d8d4f83)
• Control metadata is a building block, not the requested UI: crawlkit metadata advertises local JSON commands and marks private-message scope, but it does not add a web server or frontend surface. (internal/cli/control.go:19, 63b37d8d4f83)
• No web/frontend implementation found: Searches for net/http server, ListenAndServe, dashboard, browser, and frontend framework terms found no built-in web UI implementation in source files. (63b37d8d4f83)

Likely related people:

• steipete: steipete gave the main product-direction comment on this issue, and git history shows Peter Steinberger authored the initial CLI/archive surface, read-time sync, and crawlkit metadata that a future UI would build on. (role: product-direction commenter and primary area contributor; confidence: high; commits: 106db92c346b, b916579688d9, fb8810de77cc; files: README.md, internal/cli/cli.go, internal/cli/sync.go)
• joshp123: joshp123 authored the merged contact-export/control metadata work, which is adjacent to external UI and control integrations but does not implement this dashboard. (role: recent adjacent contributor; confidence: medium; commits: c741296dc8ef; files: internal/cli/cli.go, internal/cli/control.go, internal/cli/sync.go)
• greenido: greenido opened the request, linked the companion wacrawl-ui project as reference material, and offered to help with the direction. (role: external prototype author and feature proposer; confidence: medium)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

[alfozan]

Maybe useful reference: I’ve been building a local-first WhatsApp viewer here: https://github.com/alfozan/WhatsApp-Local-Viewer

Different scope than wacrawl, but overlaps with the dashboard idea: private local browsing, search, and media rendering on top of a WhatsApp export.