Why a sleeping Mac does not answer your coding-agent message

Build a timeline before changing settings

Begin with one message and its original identifier. Record when you sent it, which Task and computer it targeted, and the strongest confirmation currently visible. Saved on relay is evidence about storage. A computer receipt is evidence about arrival or acceptance at that stage. Agent activity is another observation, and a final answer is another still. The message delivery guide explains the current GrantTap labels. A single green connection icon cannot replace the message's own evidence, because the computer may have connected after that particular operation stopped progressing.

Add three simple observations from the Mac when you have local access: whether the system is awake, whether the required network path works and whether the intended provider session is usable. Do not change all three conditions at once. If the message appears after you open the lid and reconnect Wi-Fi, you have learned that the combined intervention helped, but you have not identified which part was necessary. A controlled timeline keeps the next experiment small and prevents a plausible explanation from being recorded as a verified cause.

For the exercise, write a harmless instruction such as asking the agent to describe a fixture file already in the test repository. Avoid asking it to edit the fixture, because a repeated read is easier to distinguish from a side effect. Put a short unique marker in the fixture so you can tell a new response from an earlier cached answer. Keep the original operation's correlation when checking status. A second message with similar wording is a second operation, even if the interface makes the two bubbles look nearly identical.

A black display is not a sleep diagnosis

A display can turn off while the computer continues executing. The system can also enter sleep, and a laptop lid or power condition can change the available behavior. Apple's battery settings guidance is the appropriate reference for the options exposed by a particular Mac. Do not turn a screenshot of a dark display into a claim about system sleep. In your test note, describe what you actually observed and how you established whether the execution process remained running.

Compare two small trials. In the first, leave the Mac awake and turn only the display off through a normal supported action. In the second, use the system's ordinary sleep action. Keep the test Task, network and provider constant. After restoring local access, inspect which trial produced a response and whether the original request remained queued. The exercise does not require changing hidden power parameters or disabling every energy-saving feature. Its purpose is to find the state boundary that matters to this workflow on this device.

A successful trial with the display off establishes a useful practical result: you may be able to leave the screen dark while that configured computer continues its work. It does not establish what happens after an unattended night, a battery threshold, a power outage or a network change. Give the result a scope. The note should include the power source, the duration and the action you used. That is more useful to another person than an absolute statement that the agent always works with the lid closed.

Separate computer liveness from provider readiness

An awake Mac can still lack a usable provider session. The CLI may have exited, authentication may have expired, or the selected Task may point to an execution that no longer exists. Check the provider and computer shown by the Task before starting a new conversation. If the computer has fresh observations but the provider cannot begin, the next useful evidence is the provider's actual refusal or sign-in state. A relay restart does not authenticate Claude Code or Codex, and a phone cache does not repair a missing local executable.

Use the provider sign-in guide and Devices controls for the supported GrantTap route. Read installed, running and available as different observations. A version string proves that a program was identified; it does not prove the intended account can start the requested operation. When a native login step is needed, complete that provider's own flow on the selected computer. Avoid copying credentials into a chat merely to make a troubleshooting record look complete. A concise authenticated or not-authenticated result is enough.

For a clean comparison, first run the fixture Task locally while the Mac is awake. Then repeat the supported mobile continuation in that same Task. If both fail with the same provider error, focus on the local prerequisite. If local work succeeds but the mobile operation has no computer receipt, focus on routing and transport. If arrival is confirmed but no provider activity follows, inspect the continuation's native admission state. Each outcome narrows the problem. Treating every silence as sleep would hide all three distinctions.

Test the actual network path

The phone having cellular data says little about the Mac's connection. A hotel network, a switched Wi-Fi access point, a captive portal or a disconnected cable can affect the execution computer independently. Start with the exact service route the configured setup uses. A successful request to an unrelated website establishes only general connectivity, not that the relay path and its authentication are available. Conversely, a failed ping is not a complete diagnosis of an application connection. Use the application's own connection evidence wherever it can identify the relevant stage.

A useful practice sequence is to establish one working baseline, interrupt the test computer's network through its normal controls, then restore that same network. Observe the original message rather than submitting another copy. Record when the Mac was last confirmed available and when a fresh observation returned. If the Task is routed to a different computer, stop the experiment and correct the route before interpreting the result. A recovered connection on Mac B does not prove that an instruction intended for Mac A was received.

Check what happens when the phone's network changes as a separate trial. Keep the computer awake and online, send the harmless fixture message, and then switch the phone between its normal Wi-Fi and cellular connection. On return, inspect the same operation's status and history. This trial tests controller reconnection rather than waking the host. Separating the two makes it possible to report a precise failure, such as a stale phone display after reconnection, without incorrectly describing an otherwise healthy computer as offline.

Understand what wake settings can and cannot establish

Some Macs expose options related to waking for network access, with behavior depending on hardware, power and the configured service. Apple's documentation describes those supported scenarios; it does not establish a universal remote wake path for any coding agent. A product should explain a tested wake mechanism explicitly before you rely on it. In a GrantTap workflow, a relay-stored instruction and a configured wake-related setting are still separate facts. Neither is proof that a sleeping host has resumed and launched the intended provider operation.

For important unattended work, choose a host arrangement whose availability you can actually verify. That might be a suitably configured powered Mac or another already authorized execution computer in the same project. The choice should follow your operating requirements, not a promise inferred from a marketing screenshot. If a supported Task route cannot reach its selected computer, retain that fact and its recovery path. Do not quietly redirect a local workspace to a different machine just because the second machine happens to be online.

Treat power changes as their own operating decision. Explain the period for which availability is needed, the power source and the behavior you expect when the work ends. Then use normal supported settings appropriate to that device. This article does not require keeping every laptop awake permanently. A short supervised test can show whether the chosen arrangement is sufficient for a particular session. Leaving a machine in an unexplained always-on state creates a new maintenance problem while still failing to prove the original message was delivered.

Recover the original operation after a long interruption

When the Mac returns, first refresh evidence for the original instruction. Check the Task's visible conversation and the original delivery identifier before choosing Retry or a manual queue action. A response that appeared while the phone was disconnected is stronger evidence than a stale status label left on the controller. The queue guide explains the supported difference between waiting work and an operation already admitted by an agent. A receipt refresh is valuable precisely because it can inspect the prior operation without creating another instruction.

If a retry is necessary, use the product's defined recovery action and read its meaning. Repeating a transport attempt with the original identity is different from starting a new turn with the same text. No user interface can honestly promise universal exactly-once execution across arbitrary old clients, expired histories and external side effects. The practical goal is to preserve correlation, consult durable evidence and avoid automatic replays that outlive the system's supported recovery contract. A manual new instruction should be an intentional decision made with knowledge of the earlier one.

Pay particular attention to tasks with side effects. Asking whether a build finished is a read; publishing another build or issuing another customer email changes the world. After a long unknown interval, inspect the external system's actual state before authorizing a second side effect. Use an artifact identifier, a commit or a service record that belongs to the original attempt. The absence of a final chat answer does not prove the operation never happened. This is a general recovery principle, not a reason to distrust every delayed read-only question.

Preserve local work while restoring connectivity

Connection repair should not discard the workspace that made the Task useful. Before clearing anything, distinguish a controller's cached history from the repository, its uncommitted files and the provider's native session. The cache and storage guide describes the current controls and their scope. A cache cleanup can free device storage, but it is not a substitute for preserving source changes. Similarly, an app reinstall should not be the first experiment when the only known fact is that a computer stopped sending fresh observations.

For a practice session, deliberately create one harmless uncommitted change in a dedicated test checkout, then perform the connection experiment without deleting that folder. After recovery, confirm both the message history and that local change. This makes a useful acceptance test: connectivity returned without silently replacing the working copy or losing the pending edit. Keep the example isolated from real release branches. The goal is to check a preservation property with data you can recognize, not to expose an important project to an unnecessary recovery procedure.

If the original provider process ended, record that separately from the saved Task. A stable Task identity can help you continue the work, while the next execution may be a different native session. Inspect the available history and project context before asking the new execution to proceed. Do not assume it retained in-memory state from the old process. A compact handoff note should identify the repository, relevant files, last verified result and the next step. That note makes continuation useful even when waking the original process is no longer an option.

Measure recovery instead of timing the whole silence

A total wait of three minutes mixes several possible delays: relay storage, computer availability, provider admission, execution and controller refresh. Write separate timestamps for the observations you can actually see. Unknown stages stay unknown. If the Mac was asleep for most of the interval, the duration is not a model latency measurement. If the provider began promptly but its answer took time, it is not evidence that the relay held the request. Stage-specific timing turns an emotional report of slowness into a repairable engineering question.

Repeat a small test several times only when repetition will answer a question. A normal awake baseline, one deliberate sleep trial and one deliberate network interruption are usually more informative than ten uncontrolled sends. Keep message identities distinct across trials and preserve the original identity within each recovery. Report the range and the test conditions rather than presenting the fastest sample as a guarantee. A measured result from one computer and network is a useful observation; claiming it as universal behavior would remove the context that makes it trustworthy.

Include the observer's limits. A phone screen recording may show when a label appeared, while a local provider log may establish when execution began. Those clocks and event meanings need not be identical. For this workshop, a simple ordering of independently confirmed events can be enough. If you need precise latency budgets, define synchronized timestamps and the measurement source as a separate engineering task. Do not manufacture millisecond precision from a screenshot containing only minute-level time and an animated waiting indicator.

Finish with an availability plan you can explain

Write the operating plan in ordinary language: which computer owns the Task, when it is expected to remain awake, which connection route is required and how you will recognize a provider that needs sign-in. Add the supported recovery action for an unconfirmed instruction and the place where completed artifacts can be checked. This is a practical plan for one workflow, not a promise of permanent availability. It helps a teammate know whether to wait, restore a prerequisite or inspect a completed result without guessing.

Retest after a meaningful change such as a new power arrangement, a different network, an updated runtime or a changed execution computer. Use the same small fixture so a different outcome has a recognizable baseline. You do not need to repeat every experiment after editing an unrelated source file. Match the test to the change that could affect availability. This keeps maintenance proportionate and makes the evidence useful: the team can see why a previous result still applies or why a particular assumption needs to be checked again.

A successful end state is concrete. The chosen computer can execute the harmless Task under the documented conditions. The controller distinguishes storage, arrival, activity and response. A deliberate interruption can be recovered without creating a duplicate instruction or losing the test checkout. Remaining wake or background limits are named explicitly. Once those properties are visible, a black display stops being a mysterious explanation for every delay. It becomes one observation in a system whose next useful action you can determine from evidence.

A small test notebook can be enough to preserve this knowledge. Give each trial one row containing the computer, power state, network condition, original message identifier and strongest confirmed outcome. Keep an unresolved column rather than forcing every trial into success or failure. If an answer appeared but the status remained stale, record both facts. That combination points to a display or reconciliation problem and preserves the successful execution as evidence. It is much more useful than a rewritten summary that says only that the system did not work.