AI Agent
📅 2026-10-07 ⏱️ 9 min read Dean Dean

FoneClaw Discord Connection Not Working? Android AI Agent Fixes

Troubleshoot your FoneClaw Discord connection to an Android AI agent: check pairing, queued requests, phone approvals, and missing replies without repeating actions.

Conceptual illustration of a Discord direct message connected to an Android phone, with pairing, task queue, approval, and result-delivery stages
📋 Key Takeaways
  • FoneClaw’s Discord connection uses text direct messages to a bot. Check bot setup and pairing before investigating the phone task; Discord voice-call settings are a different issue.
  • Enable Message Content Intent, save the bot token in FoneClaw, and send hello by direct message within ten minutes. The first Discord account that sends a message becomes bound.
  • Use /status to inspect running and queued requests, then check actual Android permissions, pending approvals, and the saved destination on the phone.
  • Use /retry for a recoverable saved result’s delivery, not to rerun the phone action. Inspect existing changes before resending; /stop does not undo completed operations.

Find the Stage That Failed

If your FoneClaw Discord connection is not working, first distinguish a missing connection from an unfinished phone task or an undelivered result. Our Discord entry uses text direct messages to a bot. It is not a Discord voice call, microphone route, or Bluetooth connection.

Keep the original request and its time before sending anything again. A missing reply does not establish that the Android action failed. The phone may already contain the item you asked to create.

What you observeNext check
Token or connection errorBot token, Message Content Intent, and network
No pairing confirmationCorrect bot DM, intended account, and ten-minute window
Request appears queuedRunning and queued counts through /status
Task awaits approval or permissionPending step on the Android phone
Phone result exists but Discord reply is missingSaved-result delivery and /retry
Outcome is unclearPhone task record and actual destination before resending

Work through the first unresolved stage. A valid connection does not prove a request was accepted, and acceptance does not prove completion. Likewise, completion on the phone and delivery back to Discord are separate outcomes.

If your actual problem is audio in a Discord call, use How to Test Voice on Discord Mobile: Android Mic and Bluetooth Fixes. The checks below concern the FoneClaw text connection.

Check the Bot Setup and Credentials

Use the bot setup required by FoneClaw, rather than adding unrelated Discord permissions in an attempt to make the connection work. Discord’s bot overview explains the Developer Portal, bot credentials, and installation process.

  1. Create the bot. Use Discord Developer Portal and confirm you are configuring the bot you intend to connect.
  2. Enable Message Content Intent. FoneClaw’s setup explicitly requires it.
  3. Install the bot to a server through OAuth2. Follow the supported installation flow.
  4. Copy the bot token privately. Use the credential belonging to this bot.
  5. Paste the token into FoneClaw and save. Read the connection response before proceeding to pairing.

Discord’s Gateway documentation identifies Message Content as a privileged intent configured in the Developer Portal. Enable the named setting and follow any platform requirements that apply. Do not substitute a different intent or assume more server permissions will resolve this specific error.

An invalid token response means Discord did not accept the token. Check that you copied the intended bot’s current token and saved it in the correct FoneClaw connection. Do not post the token to ask someone else to inspect it.

For a Message Content Intent error, enable that setting, then use the indicated Retry control. For an unavailable connection, check network access, the bot token, and the intent. Change one relevant setting at a time so you can identify whether the response changes.

Keep credentials out of screenshots, messages, and diagnostic records. If a token has been exposed, rotate it through the official Developer Portal and update the saved credential in FoneClaw. Routine troubleshooting does not require publishing or repeatedly replacing a private token.

Installing the bot to a server is a setup step. It does not make server-channel messages the supported request route; continue in the bot’s direct-message conversation.

Pair the Intended Discord Account

After saving the bot token, send hello to the bot by direct message within ten minutes. The connection binds to the first Discord account that sends a message. Check which account is active before beginning, particularly if you use separate personal and work accounts.

Open the installed bot’s profile and its direct-message conversation. Confirm the recipient is the bot you configured. Writing hello in a server channel does not complete the documented DM pairing flow.

  1. Check the intended Discord account and bot identity.
  2. Start the pairing flow from FoneClaw.
  3. Send hello in the bot DM within the pairing window.
  4. Read the pairing response and check the connection state in FoneClaw.
  5. Only then proceed to a status check or bounded request.

If pairing expires, start pairing again from FoneClaw rather than continuing to send messages against the expired window. If you used the wrong conversation, return to the intended bot DM and check whether pairing is still active.

If another account sent the first message, stop before requesting phone actions. Review the bound-account state and the pairing controls available in FoneClaw. Do not assume a later hello from your preferred account overwrites the existing binding, or try to solve an account mismatch by sending requests from several accounts.

Successful pairing identifies the Discord request entry. It does not grant every Android permission or approve every future tool action. Those controls remain separate on the phone.

Read Queue and Phone Task State

Once paired, send /status in the bot DM to inspect running and queued counts. Use that response to separate a request waiting for execution from a task already running. Do not add repeated copies of the same instruction merely because the final reply has not arrived.

A queue full response directs you to wait or use /stop. Choose stopping only if you intend to stop the current and queued requests. A queue stopping response means you should try later, after checking the state, rather than immediately adding more work.

If a request is running or has reached a blocked step, open FoneClaw on the Android phone. Inspect the task’s actual state, any pending approval, and the permission needed for the requested tool. Approve only the intended action; resolve a missing Android grant only when that task needs it.

Our configured model interprets and plans the request. Enabled supported Android tools execute under actual Android permissions and global and per-tool approval settings. The Discord connection is an entry point to that process, not a replacement for its controls. Not every action necessarily prompts for approval.

Check the result where it belongs. For a personal To-do, inspect the saved wording and date category. Without an anchored date, it should remain Unscheduled. For a calendar action, check the intended date, time, account, and calendar destination.

A working status response is useful evidence that the command reached the connection, but it does not prove a particular earlier request completed. Keep the request, queue state, approval state, and destination result separate in your notes.

Our FoneClaw Features page describes supported Android actions. If the Discord entry works but the underlying phone task still fails, Phone Agent Debugging and Recovery: Fix Failed Android AI Assistant Tasks covers that different recovery path. Avoid broad permission changes or resets as a substitute for identifying the blocked step.

Recover the Reply Without Repeating the Action

/retry queues a saved result for delivery. It is not a command to rerun the Android task. This distinction matters whenever a request could create or change something.

Consider this proposed example: you request one calendar event with a definite date, reviewed time, reminder choice, and intended calendar. The event appears on the phone, but the Discord reply is missing. The phone action and the return message now have different outcomes.

  1. Open the intended calendar and find the event.
  2. Check its title, date, start and end times, and destination.
  3. Review the corresponding FoneClaw task state.
  4. If a recoverable failed result delivery exists, use /retry to queue that saved result for delivery.
  5. Check the delivery response separately from the existing event.

Sending the original creation request again could create a second event. The same problem applies to personal To-dos or other completed writes. Recover the reply first when the action has already succeeded.

If the response says no recoverable failed delivery, there is no saved failed result available through that recovery path. It does not establish that the original phone action never happened. Inspect the task and destination before deciding whether a fresh request is appropriate.

A request expired or connection changed response also calls for inspection. Confirm the current connection and phone state before sending again. Do not assume an old result can be recovered through a different connection, or that changing the connection reversed an earlier write.

Use /stop when you intend to stop current and queued requests. It does not undo completed operations. If an event already exists, stopping further work leaves that event to be reviewed and, if necessary, corrected separately.

Our security guidance explains the role of Android permissions, tool approval, and external side effects. For a focused stopping workflow, How to Stop an AI Agent on Android and Check What Continued helps you inspect what happened before stopping.

When the outcome remains uncertain, keep it recorded as uncertain. A timeout, absent message, or unavailable recovery result is not enough evidence to label a write unsuccessful and safely repeat it.

Check Recovery and Collect Safe Diagnostics

After fixing setup or pairing, begin with /status, not a request that sends a message or creates an appointment. This is a proposed recovery check, not a reported connection test. Read the returned running and queued counts, then compare them with the task state visible on the phone.

If you need a second check, request short proposed wording only, such as Draft a personal checklist for packing lunch. Do not save or send anything. Review whether that request reaches FoneClaw and whether its result returns to the bot DM. This checks more of the request path without deliberately creating a calendar item or sending a communication.

For a useful diagnostic record, capture:

  • The exact error or response, with secrets removed.
  • The time and approximate order of the request and failure.
  • Whether setup and pairing completed, and whether the intended account was used.
  • The running and queued counts shown by /status.
  • Any pending approval or Android permission step.
  • Whether the destination item already exists.
  • Whether /retry found a recoverable failed delivery.
  • Any connection change or /stop request made during recovery.

Crop or redact screenshots before sharing them. Remove bot tokens, private message content, personal calendar details, and unrelated account information. A configured online model may process supplied task context, so keep troubleshooting requests limited to the information needed.

If you choose a different messaging entry, Connect FoneClaw to a Telegram Bot: Private Setup Guide covers that separate configuration. Do not reuse Telegram credentials or pairing assumptions for Discord.

Finish with four observable checks: the intended account is paired, requests have a known queue state, the phone task has a known outcome, and result delivery has been checked. Resolve the remaining stage before sending a fresh action request.