Safe Usage
Operating rules that reduce account and privacy risk.
Introduction
There is no honest way to describe this project as zero-risk. The real question is how to keep risk narrow, reviewable, and easy to explain.
The safest use of OpenKakao is not maximal automation. It is controlled local automation with explicit boundaries.
Read-first posture
Start with reads, exports, and summaries before you add any outbound behavior.
Narrow operating scope
Limit chats, triggers, keywords, and destinations so the workflow stays easy to reason about.
Human review over autonomy
Drafting, triage, and classification are safer default uses than unsupervised replies.
Assume failure modes matter
A technically working workflow can still be noisy, suspicious, or unsafe in practice.
Safe usage is mostly about restraint
The biggest risk reduction usually comes from reducing scope, reducing frequency, and reducing side effects.
Unsafe automation can cost the account
Treat policy enforcement as an account-level risk, not just a workflow failure. If Kakao interprets your use as abusive or non-compliant, your account may be suspended or permanently deleted.
Prefer These Usage Patterns
- start with read-only commands first
- test on low-stakes chats before automating anything outbound
- keep automation frequency low and purpose-specific
- review generated messages before enabling unattended sends
- store exports locally and deliberately
Be Careful with These Patterns
- high-volume sending loops
- automatic replies in public or open chats
- broad scraping of all conversations without a clear need
- forwarding sensitive chat content into external AI or SaaS tools
- cron jobs that keep retrying on auth or server errors without supervision
Open Chat Caution
Open chats are a higher-risk surface. If you are automating sends there, assume the bar for suspicious behavior is lower and use the strongest possible restraint.
Rate Limiting by Chat Type
Different chat types have different risk profiles and should be treated with different frequency limits:
| Chat type | CLI flag | Recommended behavior |
|---|---|---|
MemoChat (memo) | none needed | Safe for frequent testing and automation dry-runs |
DM / Group (dm, group) | default | Normal operation; keep send frequency reasonable (seconds between messages, not milliseconds) |
Open chat (open) | --force required for full-history reads (--all) | High ban risk; the CLI enforces a 500ms minimum delay between read batches; keep sends infrequent and purposeful |
For automation loops, build in explicit delays between operations:
- Reads: The CLI enforces 500ms minimum delay for open chat SYNCMSG batches. For DM/group chats, the default 100ms
--delay-msis reasonable. - Sends: No built-in rate limiter. Your automation code should enforce its own send interval. A minimum of 2-3 seconds between sends is a safe starting point.
- Watch hooks: Controlled by
safety.min_hook_interval_secsandsafety.min_webhook_interval_secsin config.
Open chats require --force for full-history reads (--all flag) precisely because the risk is higher. Single-page reads and other operations do not require --force. If your workflow touches open chats, keep the scope as narrow as possible and monitor for any account warnings.
Machine Hygiene
Run on a machine you control
The host matters because the CLI necessarily touches sensitive local app state and credentials.
Treat the credential file as privileged
~/.config/openkakao/credentials.json should be handled like authentication material, not disposable cache.
Review automation code
Shell snippets, hooks, and agent wrappers can widen risk much faster than the base CLI does.
Keep exports deliberate
Shared folders, synced drives, and third-party APIs create new privacy surfaces immediately.
- use a machine you control
- protect your user account and disk
- treat the credential file as sensitive material
- avoid running ad hoc automation copied from unreviewed sources
Incident Response Mindset
If anything looks wrong:
- stop unattended jobs
- inspect saved credentials and shell history
- rotate or refresh auth state as needed
- narrow the workflow before turning it back on
Do not debug by widening the workflow
When something fails, the wrong move is often to add more retries, more hooks, or broader permissions. The right move is usually to shrink the surface until the problem is understandable again.
Good Default Policy
If you would be uncomfortable explaining a workflow to yourself six months later, it is too broad. Keep the command surface small, the data path local, and the side effects obvious.