Session idle timeout

The idle session timeout signs members out after a period of inactivity. It is configurable per organization, off by default, and composes correctly when a member belongs to multiple orgs (the shortest configured timeout wins on that device).

Open Settings in your workspace sidebar and find the Idle Session Timeout section.

What it does

When a member is signed in to your organization's workspace and hasn't interacted with the app for the configured number of minutes, the app shows a warning 60 seconds before the cutoff. The warning says "You'll be signed out in N seconds" and gives two buttons: Stay signed in and Trust this device for 30 days. If they don't click either, the app signs them out at the cutoff and sends them back to the login page with a reason=idle flag in the URL.

"Interaction" means a click, a keystroke, a scroll, or a touch event. Mouse movement alone does NOT reset the timer (intentional: mouse-jiggler bypasses are trivial, and counting mouse movement as activity makes the timer effectively useless during normal reading).

Picking a value

The picker offers Off (no enforcement), 15 minutes, 30 minutes, 1 hour, 2 hours, 4 hours, and 8 hours. The clamp on the database is 5-480 minutes; the picker is a curated subset of common choices.

There's no "right" answer; pick the value that matches your org's threat model. A few reference points:

• High-sensitivity orgs (handling sensitive contact data, donor information, internal strategy) commonly use 15-30 minutes. The friction is real (members get the warning during long meetings), but the protection against a forgotten-logged-in laptop is meaningful.
• Standard orgs often pick 1 or 2 hours, which catches forgotten devices overnight but doesn't disrupt an afternoon of work.
• Off is a defensible choice if your members are all on personal devices and you'd rather trust their own session management than impose one.

The setting takes effect on the member's next page load. They don't get a notification when you change it.

Trust this device for 30 days

The 60-second warning panel includes a Trust this device button. Clicking it stores a per-org localStorage entry on that browser, valid for 30 days. While trusted, the idle timeout does not fire on that device for that org. After 30 days, the entry expires and the timeout resumes.

A few notes on the semantics:

• The trust is per-org AND per-device. Trusting a laptop for your org has no effect on the same member's phone or on their access to other orgs.
• A logout clears the trust. If a member explicitly signs out (vs. timing out), the device is no longer signed in and the localStorage entry becomes irrelevant. Signing back in re-arms the timer; they'd need to re-trust if they want to.
• Clearing browser data clears the trust. The entry lives in localStorage.

There is no admin-side toggle to disable trust-this-device. If you want to disable it for your org, the option doesn't exist today. The reasoning: idle timeout without a trust affordance is hated by users (it disrupts long meetings, long reads), and the affordance is conservative (per-device, 30 days, scoped to one org).

Multi-org members

A member who belongs to multiple orgs gets the shortest configured timeout across those orgs on a given device. If your org has 30 minutes set and they're also in an org with 15 minutes, they experience 15 minutes.

The "trust this device" affordance writes one localStorage entry per contributing org. Trusting on a device while two orgs are contributing the timeout writes both entries; trusting only suppresses the timer when all contributing orgs are trusted.

This is intentionally privacy-conservative: a permissive org can't loosen a stricter org's policy by membership overlap.

Why this matters

Forgotten-logged-in devices are one of the most common ways that organizational accounts leak. A 30-minute idle timeout on a shared coworking-space machine, a left-open laptop at a coffee shop, a roommate's curiosity all become non-events if the session is gone by the time anyone interacts with the device. Combined with enforced 2FA for admins and active-session visibility, you've covered the realistic surface for unattended-device attacks.

The idle timeout does not protect against every threat. A stolen unlocked device still exposes what the member sees; the enforcement is client-side, so a JavaScript-disabled client bypasses it (though the app is also non-functional in that state); and a malicious browser extension that reads the auth session tokens has full access regardless of the timer. For threats at that level, the answer is a different device-management posture (MDM, dedicated devices) that lives outside OrganizeOS.