Start your 3-day free trial
Sign up to experience all premium features at no cost.
*Available only to new users. Each user is limited to one trial.
Does Linear Work in China? Access and Notification Checklist
Jason Chen
September 12, 2026· 9 min read
Linear does not have one timeless “works in China” result for every network, workspace, and client. Its official documentation describes web, desktop, mobile, offline, login, Inbox, and notification behavior, but that is not a reachability guarantee for every mainland China connection. Remote teams should test the exact identity and workflow they depend on. Linear’s client guide notes that desktop and mobile apps exist alongside the web app and that offline changes are queued for later synchronization［1］.
Key Takeaways:
- Verify login, Workspace selection, Issue and Project reads, a reversible write, sync, Inbox, and the required notification channel.
- Treat web, desktop, and mobile as separate clients; do not infer one from another.
- An offline or cached Issue is not evidence of a fresh successful request.
- Keep a second Workspace administrator and an approved fallback for urgent triage.
- Record each observation with its time, network, client, account, object, action, and control result.
What Does “Linear Works” Mean?
The meaningful unit is an end-to-end task. A user must authenticate with a method allowed by the Workspace, select the correct Workspace, open current Issue or Project data, submit an authorized change, observe synchronization, and receive the notification channel that the team actually relies on. Linear documents supported login methods, including email and identity-provider options, while Workspace policy can narrow what is accepted［2］.
| Layer | Controlled check | Positive evidence | Keep separate from |
|---|---|---|---|
| Identity | Fresh sign-in with the approved method | Correct account reaches the target Workspace | A remembered local session |
| Workspace | Open a known Team and Project | Current names and membership are visible | Access to another Workspace |
| Read | Refresh a designated test Issue | A recent server-side marker appears | Previously cached Issue text |
| Write and sync | Add a harmless label or comment, then revert | Another member sees the change | A local optimistic update |
| Inbox | Trigger one assigned or mentioned event | New event appears with the right Issue | An older unread item |
| Notification | Observe the required email, desktop, mobile, or channel event | Timestamp matches the test | Inbox success alone |
Do not collapse these rows into one green or red status. A team can read data while writes remain queued, complete a write while Inbox delivery is delayed, or receive email while the current client cannot synchronize.
What Should the Team Prepare Before Travel?
Document the Workspace, Team, Project, and safe test Issue by canonical link. Confirm which login method the traveler must use and whether the organization enforces SAML, passkeys, email codes, or another identity rule. Complete enrollment and recovery before departure. Keep recovery information in the approved credential system, not in a Linear Issue.
Install only the clients the organization supports. Linear’s app guide distinguishes browser, desktop, and mobile experiences and explains offline behavior［1］. Update each required client, sign in, and confirm that links open in the intended Workspace. If the workflow depends on browser extensions, Git integrations, Slack, email, or mobile push, list them as separate dependencies rather than assuming they follow core Issue access.
Create a harmless fixture Issue with no customer information, secret, live incident data, or misleading deadline. Define the precise edit, expected synchronization behavior, Inbox event, notification recipient, cleanup step, and maximum retry count. Confirm a colleague can observe the server-side result from a different known-good path.
Assign two escalation roles: a Workspace administrator who can inspect identity and membership, and an operational owner who can make an urgent triage update without using the traveler’s account. Record their approved contact path and coverage hours.
How Should the Team Test Linear from Mainland China?
Begin on one managed device and one known network. Sign out or use an approved clean profile so the login check is current. Record which login method was offered and whether the flow failed before identity verification, during a redirect, or after returning to Linear. Avoid rapid repeated code requests because they can complicate both delivery and diagnosis.
Open the target Workspace, Team, Project, and fixture Issue through saved canonical links. Refresh the Issue and look for a marker created after the last cached session. Make the predefined reversible change. Another team member should confirm it, after which the traveler refreshes again and reverts it. If the client shows a pending or optimistic state, wait only for the agreed window and label the write “not synchronized” until independent confirmation arrives.
Trigger one Inbox event and one required external notification. Linear documents Inbox as the place for updates to subscribed or relevant Issues［3］, while notification settings cover desktop, mobile, email, and integration choices［4］. Check and timestamp them independently. A successful Inbox event does not prove mobile push, and a mobile badge does not prove the current Issue write synchronized.
If policy permits, repeat the minimal sequence on one comparison network or another required client while holding everything else constant. Record the outcome as an observation for that time and path, not as a permanent countrywide verdict.
Why Can Login, Sync, Inbox, and Notifications Disagree?
Each stage has different dependencies. Login can involve Linear and an external identity provider. Workspace membership and Team access decide which objects appear. Issue and Project permissions decide what can change. A desktop or mobile client can retain local data and queue offline operations. Inbox is an in-product event stream. Email, push, and integrations add their own settings and delivery systems.
This is why “I can see my Issues” may only mean cached data, and why “I received a notification” may refer to an event created earlier. Require a current server-side marker and confirmation from a second account for important writes. Linear’s offline model is useful for continuity, but queued work should be considered pending until it has synchronized and conflicts have been checked［1］.
Notification diagnosis should start with the exact event and channel. Confirm subscription or assignment, Workspace and personal settings, operating-system permission, quiet hours, and integration configuration. Do not repeatedly modify global settings during a connectivity test; preserve a stable baseline so the administrator can interpret the evidence.
When Should Testing Stop and an Administrator Take Over?
Stop if the login destination is unexpected, the account becomes locked, verification uses an unapproved channel, Workspace identity is ambiguous, or a test would expose sensitive data. Stop when the defined retry or wait limit is reached. Do not delete local app data while unsynchronized work may exist; first preserve the issue identifiers and visible pending state according to company policy.
Send the administrator the Workspace and Team names, account identifier without secrets, client and version, operating system, network category, local timestamp and timezone, last confirmed fresh read, exact failing operation, visible error, and whether another account or network changed the result. For writes, say whether another member saw the change and whether the client still labels it pending.
The administrator can then examine identity policy, Workspace membership, Team access, client support, integrations, and notification settings. The operational owner can handle an urgent triage update through their own account. Nobody should request the traveler’s password, session token, email code, or recovery secret.
What Can a VPN Change, and What Can It Not Change?
A VPN can alter part of the network route, but it cannot grant Linear Workspace membership, override a Team’s permissions, complete identity-provider enrollment, force an offline change to resolve cleanly, or enable a disabled notification channel. It belongs only in a lawful, organization-approved comparison as one network-path variable, not as a substitute for identity, authorization, synchronization, or administration. Once an administrator approves that comparison, you can rerun the fixture-Issue sync check through AethoVPN.
When a comparison is permitted, keep the device, client, account, Workspace, fixture Issue, and test action unchanged. Note both success and failure precisely. Results from one hotel, carrier, office, province, or hour should not be extended to all mainland China networks or future trips.
What Fallback Should the Team Keep?
Prepare a compact triage form containing the Issue identifier, requested state change, owner, priority, deadline, and non-sensitive context. Send it through an independently approved channel to the operational owner. That owner makes the change with their own account and returns the resulting Issue link and timestamp. This preserves attribution without credential sharing.
If offline work is allowed, limit it to approved notes and avoid bulk edits that may conflict on reconnection. Mark every action that still needs synchronization. Keep authoritative prioritization with the designated owner, especially during incidents, so two people do not silently create competing states.
After service returns, synchronize carefully, compare server state, resolve conflicts, reconcile fallback requests, remove the fixture change, and document which layer failed. A fallback that cannot be reconciled is only deferred ambiguity.
Summary
Teams should answer the Linear question with an evidence matrix: approved login, correct Workspace and Team, fresh data, confirmed Issue write, synchronization, Inbox, and the required external notification. Prepare administrator ownership and a clean fallback before travel, and scope every observation to the tested path.
FAQ
Is a visible Linear Issue proof of live access?
No. It may be cached. Confirm a recent server-side marker or a reversible change observed by another account.
Does an offline edit mean the write succeeded?
No. It remains pending until the client synchronizes it and the team confirms the resulting server state.
Are Linear Inbox and email notifications the same test?
No. Inbox is an in-product stream; email, desktop, mobile, and integration notifications have separate settings and delivery paths.
Should web and desktop results be recorded separately?
Yes. Client state and dependencies differ, so each required client needs its own result.
What if login succeeds but the Team is missing?
Ask an administrator to check Workspace identity, membership, Team access, and identity policy before changing networks repeatedly.
Can a VPN fix a queued Linear change?
It may change routing, but it cannot guarantee synchronization, resolve conflicts, or grant object permission.
When should this checklist be rerun?
Run it before important travel and after changes to login policy, Workspace membership, device, client, integrations, or the critical workflow.
Disclaimer: This operational checklist is not legal, regulatory, contractual, or information-security advice. Follow applicable law and your organization’s policies.
Sources
- Get the app — https://linear.app/docs/get-the-app
- Login methods — https://linear.app/docs/login-methods
- Inbox — https://linear.app/docs/inbox
- Notifications — https://linear.app/docs/notifications
Sources checked 12 September 2026.
