What to Do When a Player Refuses a Minecraft Screenshare

Sooner or later a player will answer a check request with a flat "no". Some have good reasons, some are afraid, and some have something to hide. Staff who improvise in that moment tend to make things worse. The fix is to decide in advance what a refusal means, write it down, and apply it the same way every time.

Why players refuse

Do not assume guilt. Typical reasons include:

Privacy worries. They do not want a stranger looking at their computer. Our screenshare guide explains how to keep a check focused.
Fear of malware. Fake "checker" scams exist, and a cautious player is right to be careful.
Technical limits. No microphone, a shared family computer, a console or mobile device, a weak connection.
Offense. They feel accused, especially if the request was blunt.
Actual cheating. Some refuse because the check would find something. This is the minority, but it is the case you are guarding against.

You cannot tell these apart from the refusal alone, which is exactly why your reaction must not depend on a guess.

Step 1: Check your own request first

Before treating the refusal as a problem, look at what you did. Was there a documented reason? Did you say who you are, what happens, and how long it takes? Did you use an official channel? Many refusals disappear when the player gets a clear explanation. Our article on detecting cheaters shows how to make sure the request rests on evidence in the first place.

Step 2: Answer the real objection

Ask why, and listen. Then address the specific worry:

For privacy: explain what is checked and let the player close personal windows.
For safety: point to the official source of the tool and invite them to check it with another staff member in a public channel.
For technical limits: offer an alternative that works, or a later time.
For offense: acknowledge it, restate that this is a standard procedure, and that a clean result clears them.

If your server uses a code-based scan, the objection may be easier to resolve. In the Kara Detector flow, staff enter the player's name, Kara creates a single-use code, and the player opens the app, accepts, and types the code themselves. No screen sharing call is needed, and the player does not need admin rights, though some checks are less thorough without them and the report says so. This can help the shy or time-pressed player, though it is not a reason to pressure anyone.

Step 3: Apply the written rule

If the player still declines, do not decide on the spot. Apply the rule that existed before the request. A fair rule has these features:

It is public. Players can read it before they join.
It states the consequence. For example: temporary removal from competitive modes until a check is completed, or a time-limited suspension.
It is proportionate. A refusal alone is not proof of cheating, and the penalty should reflect that. Many servers choose a restriction rather than a permanent ban, so the player can return by agreeing later.
It is the same for everyone. Staff friends, donors and veterans included.
It has an appeal route. Anyone can ask for a review.

Write the final message in plain words: what was asked, that the player declined, which rule applies, what happens now and how to come back. Do not accuse, do not label the player a cheater, and do not announce it publicly.

What not to do

Do not threaten or insult. It is the fastest way to turn a cautious player into an enemy and a screenshot on social media.
Do not force access. No tricks, no pressure to run an unknown program, no "just click this".
Do not treat refusal as a confession. If other evidence is strong, act on that evidence and cite it. If it is weak, the refusal does not fill the gap.
Do not change the rules for one person. Exceptions feel like favoritism to everyone else.
Do not delete the conversation. Keep the thread; you will need it if the player appeals.

Document everything

Record the reason for the request, the exact wording you used, the answer, and the action taken. This protects both the player and the staff member. When the case comes back through a ticket, the reviewer can see that the process was followed. The structure in our ban appeal checklist works well as a template for these notes.

Offer a way back

A refusal should not be the end of the story. Tell the player what they can do to regain access: complete a check later, request a different method, or appeal. Many players come back a day later, calmer and willing. A good policy rewards that, and honest players remember how they were treated.

Next step

Fair handling starts with clear rules and a check that is easy to agree to. A short, code-based flow gives hesitant players one fewer reason to refuse. You can compare Kara Detector plans (monthly, cancel anytime) and see how a Kara check works before you decide.