Googleカレンダーの権限 not working: what to check, in order

Access was granted and the calendar still does not appear on the other person's screen. Or it appears, but every entry reads as a busy block. Or it appears in a browser and refuses to show up in the Mac's Calendar app. All three get reported with the same sentence, which is that the permissions are broken, and all three have causes in different places.

Working through this by touching settings in the order they come to mind takes hours. Working through it by classifying the symptom first and then checking from the top layer downward usually takes minutes. What follows fixes that order.

Three symptoms, not one

Before opening any settings screen, decide which of these is happening.

The calendar does not appear in the other person's list at all. The calendar appears but every entry shows as busy with no detail. The calendar appears with detail, but editing is refused.

The first points at a grant that never completed. The second points at a grant that completed and is then being narrowed by something above it or by the events themselves. The third points at a level that does not include editing, or at an organisation setting that overrides it.

There is a fourth case that sits outside this list. If the problem appears only on the Mac and the same account looks correct in a browser, the Google side is fine. Nothing in Google Calendar's sharing settings will change anything, and time spent there is wasted. That case is a device sync question and is handled further down.

Check whether the invitation ever landed

Start with the first symptom, the calendar that never shows up.

Sharing in Google Calendar is not finished at the moment of granting. The recipient gets an email, and the calendar joins their list only after they click the link inside it. Google's help page lists the steps for when that email cannot be found: confirm the address, have the person check spam and trash, have them search their mail, and then remove them from the sharing list and add them again.

The last step is the one that resolves this most often. The granting side sees the recipient's name sitting in the sharing list and concludes the grant is live. The recipient, whose invitation went to spam and was purged, has nothing. Both views are internally consistent and neither reveals the problem. Removing and re-adding generates a fresh invitation.

A grant made to a group address fails differently and is harder to spot. Access follows the membership list, so a person removed from the group loses the calendar and a person added to it gains one, without anybody touching the sharing settings. A report of "this was visible yesterday and is gone today" from a calendar nobody has reconfigured usually traces back to the membership list rather than to Calendar at all. The sharing screen shows only the group name, so nothing on the granting side changes appearance when this happens.

Address mismatches produce the same result. A recipient who holds both a personal and a work Google account will not think to question which one is signed in, and a calendar shared to the account they do not use is invisible from the account they do. Checking the granted address against the signed in address takes a moment and ends this class of problem.

Check the ceiling before checking the level

Now the second symptom, where the calendar is visible but the contents are not.

On a work or school account, the first thing to suspect is not the sharing level. An administrator sets a limit on how much calendar information can leave the organisation, and users cannot exceed that limit. Google's administrator documentation states plainly that when external sharing is capped at free/busy, individually shared events still show only as busy. The granting side's screen shows a detail level grant. The recipient sees busy blocks. Both are accurate.

Three properties of that setting decide where to look. External sharing and internal sharing are configured separately, which is why the same calendar can read correctly for colleagues and incorrectly for an outside collaborator. Secondary calendars created by users have their own configuration, separate again from primary calendars. And where settings exist at both the organisational unit and the group level, the group setting wins, so checking only the department's configuration can produce a confident and wrong conclusion.

Timing matters too. Administrator changes take up to 24 hours to propagate, though they usually take less. A configuration checked ten minutes after an administrator adjusted it has not necessarily failed.

The third symptom, where the calendar reads correctly but editing is refused, follows the same order. If the organisation's external option stops at "all information, but outsiders cannot change calendars", no level chosen on the individual side gives an external collaborator write access. Raising the grant and asking them to try again produces the identical result, repeatedly. For an internal colleague the grant itself is the right thing to inspect, because the internal and external settings are independent. Establishing which side of that boundary the person sits on takes one question and removes an entire category of fruitless attempts.

Some invisible events are working correctly

Not every missing detail is a fault. Two mechanisms hide content on purpose and both get reported as bugs.

An event set to private shows as a busy block even to someone holding detail access to the calendar. When the report is "one specific event has no detail", the sharing level is the wrong thing to inspect. The event's own visibility setting is the right one.

The second mechanism is the sharing level named "make changes, private events as free/busy". A recipient holding it sees a private event marked Busy as a detail free block, and does not see a private event marked Free at all. The second half of that produces reports of events disappearing. Nothing has disappeared. The level and the visibility setting have combined exactly as documented.

A useful test separates a real fault from a working configuration in about a minute. Create a throwaway event on the calendar in question, leave its visibility at default, and ask the person to reload. If the test event carries full detail and the original does not, the calendar level is fine and the original event's own visibility is the answer. If neither appears in detail, the problem sits above the event layer, in the grant or the organisation ceiling. Skipping this test is what leads to the sharing level being raised and lowered several times with no change in the reported symptom.

Recurring events generate a related report: an attempt to make one occurrence private appears to have hidden the entire series. A series carries one visibility setting for all of its occurrences, so changing one changes all. An occurrence that needs to differ has to be detached first.

Tasks follow separate rules again. A task with no start and end time is always private and no sharing level exposes it. A task that has times becomes visible only at "make changes and see event details" or above. Reasoning about tasks as though they behave like events produces conclusions that do not match the screen.

When the browser is right and the Mac is wrong

This is the most common symptom of all, and its cause has nothing to do with Google Calendar permissions.

When a Google account is added to the Mac's Calendar app, the calendars that sync automatically are the ones under My calendars, plus Birthdays. A calendar shared by somebody else does not live there. It lives under Other calendars, and is therefore outside the automatic set. Getting it onto the Mac requires visiting the Calendar sync page on the Google side, ticking that calendar, saving, and then refreshing in the Calendar app.

There is a second trap in the same area. Apple Calendar has a Delegation feature under account settings, and Google's documentation notes that anything left checked there prevents calendar sync from working. An account that used to be configured through delegation carries those checkboxes forward, and the symptom is a sync that silently does nothing.

Refresh frequency is the third thing to inspect on that screen. A long interval means a permission change made on the Google side will not be reflected locally for a while, which reads as a failed change rather than a pending one. A manual refresh settles it.

Account confusion is common on the Mac specifically. A machine with two or three Google accounts added shows several similarly named calendars in one list, and a sync setting adjusted under the wrong account does nothing while appearing to have been done. The calendar list groups entries by account, so confirming which account a missing calendar belongs to before opening any settings screen prevents a long detour.

One more case: a device that synced under a wider grant may keep displaying restricted detail after the grant is narrowed. Administrator documentation covers this and the remedy is to wipe the device's data for that account and resync, rather than to keep adjusting the sharing level.

Check that the feature exists before debugging it

Some of what gets debugged was never available. This is the most expensive category, so it belongs early in any real investigation.

Google documents three Calendar features that do not work through Apple Calendar: email notifications for events, creating new Google calendars, and the room scheduler. Reports that a shared colleague is not receiving event emails, or that a new calendar cannot be created from the Mac, are not permission faults and no permission change addresses them.

App level access is also two separate grants, and the failure modes differ enough to tell them apart. The Google account grant appears in the connected apps list in account settings; when it is missing or revoked, the app shows no calendars at all. The macOS grant lives in System Settings under Privacy and Security, in the Calendars entry; when it is missing, the app never reaches the point of asking Google for anything.

Finally, some functions stop by design when access is narrowed. Two way sync, replying to meeting invitations, and calculating travel time between consecutive events all require both read and write. After a switch to read only, none of them work, and that is the documented outcome rather than a defect.

What to change first

Run the checks top down: did the invitation land, is there an organisation ceiling, is the event itself private, and is the Mac syncing the calendar at all. Most reports resolve in one of those four places, and the order keeps unrelated settings untouched.

What remains afterwards is usually structural rather than a fault. Shared calendars going missing on a device gets more likely as the number of calendars grows, which makes it worth seeing how they sit together on one screen in Features, and worth checking how quickly an event can be created when a narrower grant means more of them get typed by hand, covered in Entering events. The differences against other options are set out in Compared with other calendars, and Caltimate is where the pricing sits.