sms-inbox-manager
Maintains a self-hosted SMS inbox service. Use for inspecting received messages, managing logs, or restarting the service.
Install
mkdir -p .claude/skills/sms-inbox-manager && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/17273" && unzip -o skill.zip -d .claude/skills/sms-inbox-manager && rm skill.zipInstalls to .claude/skills/sms-inbox-manager
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Maintain a self-hosted realtime SMS inbox service. Use when inspecting received SMS messages, managing the web UI, debugging SMS forwarding, restarting or enabling the service, adjusting authentication, updating nginx routing, or locating data/log files.Key capabilities
- →Inspect received SMS messages.
- →Manage the web UI for the SMS inbox service.
- →Debug SMS forwarding issues.
- →Restart or enable the `sms-request-logger.service`.
- →Adjust authentication settings via `SMS_INBOX_PASSWORD`.
- →Update nginx routing for the service.
How it works
The skill provides commands and guidance for maintaining a Python-based SMS inbox service, covering runtime checks, compilation, restarts, authentication, nginx configuration, and data/log inspection.
Inputs & outputs
When to use sms-inbox-manager
- →Inspecting received SMS messages
- →Debugging SMS forwarding issues
- →Updating authentication or nginx routing
- →Managing service logs and data storage
About this skill
SMS Inbox Manager
Context
Manage a lightweight SMS inbox served by sms_request_logger.py. The service receives forwarded SMS requests, persists them to JSON Lines, renders a password-protected list UI, highlights verification codes, linkifies URLs, and updates the browser in real time with Server-Sent Events (SSE).
Core Files
- App source:
sms_request_logger.py - Service unit example:
sms-request-logger.service - nginx example:
nginx.example.conf - Contributor guide:
AGENTS.md - Default local message store:
./data/sms_messages.jsonl - Default local raw/debug log:
./data/sms_requests.log
Production data/log paths should be configured with environment variables, not hard-coded.
Runtime Shape
- App listens on
127.0.0.1:18080. - nginx should proxy all site paths to
http://127.0.0.1:18080. - The service uses only the Python standard library and
ThreadingHTTPServer; there is no framework or database. - The frontend subscribes to
/api/streamwithEventSource; if SSE repeatedly fails, it falls back to polling/api/messages.
Routes And Auth
/: password-protected SMS list page./login: POST endpoint for password login./logout: clears the auth cookie./add?msg=...: legacy ingest endpoint for URL-encoded multi-line SMS text./add?sender=...&message=...×tamp=...: newer ingest endpoint. Optional fields includelocal_number,network_addr, andremark./api/messages: authenticated JSON snapshot of inbox stats and pre-rendered message list HTML./api/stream: authenticated SSE stream. It sends amessagesevent when the inbox signature changes and: keepalivecomments periodically./?token=<password>: authenticates via URL parameter, writes the login cookie, and redirects to/.
Authentication is controlled by SMS_INBOX_PASSWORD. Treat passwords, domains, phone numbers, and message content as sensitive.
Data Model
The JSONL store has one object per line. Important fields:
server_at: server receive time in ISO format.sender: SMS sender.content: SMS body shown in the UI.code: detected verification code, usually 4-8 digits.is_code: boolean derived from whethercodeexists.sim,sub_id,sms_at,device: parsed metadata when available.raw: original forwarded SMS payload.source_ip: requester IP when available.network_addr,remark: optional fields for ESP32-style payloads.
The UI formats timestamps as YYYY-MM-DD HH:MM:SS. Keep JSONL storage unchanged unless explicitly doing a migration.
Common Commands
Check runtime state:
systemctl is-enabled sms-request-logger.service
systemctl is-active sms-request-logger.service
systemctl show sms-request-logger.service -p MainPID -p ActiveState -p SubState --no-pager
ss -ltnp | rg ':18080\b'
Compile and restart after edits:
python3 -m py_compile sms_request_logger.py
sudo systemctl restart sms-request-logger.service
systemctl is-active sms-request-logger.service
Local development:
SMS_INBOX_PASSWORD=change-me python3 sms_request_logger.py
Validate/reload nginx after vhost edits:
sudo nginx -t
sudo nginx -s reload
Inspect configured data and logs:
tail -n 20 ./data/sms_messages.jsonl
tail -f ./data/sms_requests.log
sudo tail -n 80 /var/log/nginx/realtime_sms_inbox.error.log
Local HTTP tests:
curl -sS -i 'http://127.0.0.1:18080/'
curl -sS -i 'http://127.0.0.1:18080/?token=change-me'
curl -sS -i 'http://127.0.0.1:18080/add?msg=10086%0Acode%3A%20123456'
curl -sS -i 'http://127.0.0.1:18080/add?sender=10086&message=code%3A%20123456×tamp=2026%2F06%2F28+13%3A42%3A59'
Authenticated API/SSE checks:
AUTH_HASH=$(python3 - <<'PY'
import hashlib
password = b"change-me"
print(hashlib.sha256(b"sms-inbox:" + password).hexdigest())
PY
)
curl -sS -i -H "Cookie: sms_auth=$AUTH_HASH" 'http://127.0.0.1:18080/api/messages'
curl -sS -N -H "Cookie: sms_auth=$AUTH_HASH" 'http://127.0.0.1:18080/api/stream' | sed -n '1,4p'
Maintenance Guidance
- Before editing data, back up the configured JSONL file.
- Use
apply_patchfor source edits. - Keep nginx routing broad: all paths for the public host should proxy to
127.0.0.1:18080unless changing architecture. - When changing the password, update
SMS_INBOX_PASSWORD, restart the service, and ask users to refresh/login again. - If requests do not arrive, check DNS, nginx access logs, nginx error logs, service status, and port
18080in that order. - If the UI shows stale data, check whether new lines were appended to the JSONL store, then verify
/api/streamreturnstext/event-streamand/api/messagesreturns fresh JSON with an authenticated cookie. - For real-time UI issues, remember that
/api/streamis the primary path and/api/messagesis a fallback; do not reintroduce meta refresh unless explicitly requested. - Avoid deleting request logs; they are useful for debugging forwarding issues.
When not to use it
- →When the task involves deleting request logs.
- →When the goal is to reintroduce meta refresh for real-time UI issues.
- →When the service architecture is changing significantly beyond nginx routing.
Limitations
- →The service uses only the Python standard library and `ThreadingHTTPServer`, limiting framework or database integrations.
- →Authentication is controlled by a single `SMS_INBOX_PASSWORD` environment variable.
- →The UI formats timestamps, but JSONL storage should remain unchanged unless explicitly migrating.
How it compares
This skill offers specific commands and troubleshooting steps for a self-hosted Python SMS inbox, providing targeted maintenance instructions rather than general system administration.
Compared to similar skills
sms-inbox-manager side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| sms-inbox-manager (this skill) | 0 | 29d | Review | Intermediate |
| telegram-bot-builder | 106 | 6mo | Review | Intermediate |
| async-python-patterns | 12 | 2mo | No flags | Intermediate |
| modal | 5 | 7mo | Review | Intermediate |
Try saying
Example prompts that trigger this skill in your AI assistant.
You might also like
telegram-bot-builder
davila7
Expert in building Telegram bots that solve real problems - from simple automation to complex AI-powered bots. Covers bot architecture, the Telegram Bot API, user experience, monetization strategies, and scaling bots to thousands of users. Use when: telegram bot, bot api, telegram automation, chat bot telegram, tg bot.
async-python-patterns
wshobson
Master Python asyncio, concurrent programming, and async/await patterns for high-performance applications. Use when building async APIs, concurrent systems, or I/O-bound applications requiring non-blocking operations.
modal
davila7
Run Python code in the cloud with serverless containers, GPUs, and autoscaling. Use when deploying ML models, running batch processing jobs, scheduling compute-intensive tasks, or serving APIs that require GPU acceleration or dynamic scaling.
distributed-tracing
wshobson
Implement distributed tracing with Jaeger and Tempo to track requests across microservices and identify performance bottlenecks. Use when debugging microservices, analyzing request flows, or implementing observability for distributed systems.
python-background-jobs
wshobson
Python background job patterns including task queues, workers, and event-driven architecture. Use when implementing async task processing, job queues, long-running operations, or decoupling work from request/response cycles.
opentrons-integration
davila7
Lab automation platform for Flex/OT-2 robots. Write Protocol API v2 protocols, liquid handling, hardware modules (heater-shaker, thermocycler), labware management, for automated pipetting workflows.