Compatibility status and testing methodology
This page explains how GhOst approaches compatibility and how it is tested. It is a transparency and methodology reference, not a performance guarantee. Please read it before relying on any compatibility-related expectation.
Last reviewed: July 19, 2026
What we are not claiming
We do not claim a universal, all-platform compatibility result. GhOst's privacy and compatibility behavior depends on your operating system and build, the interview or meeting platform and its version, the capture mode, your GhOst version, and your settings — so no single result can describe every environment.
A continuously verified, public compatibility matrix is not yet available. This page documents the fields, the evidence model, and the testing methodology we use to reason about compatibility — it does not publish platform-by-platform pass results.
Scope
What GhOst documents today
Operating systems
Windows and macOS, delivered as a native desktop application.
Interview types
Coding, behavioral, and system-design rounds.
AI access
Managed AI — there are no API keys to configure.
This scope describes what GhOst is designed for. It is not a statement that GhOst has passed, or will pass, any specific screen-share, recording, or proctoring check on any specific platform, operating system, or version.
Method
Compatibility record fields
Every compatibility claim must carry a complete, dated record. These are the fields we require before any result is considered testable.
OS / build
The operating system name plus its version and build number (for example, a specific Windows or macOS release).
GhOst version
The exact GhOst application version under test.
Platform / version
The interview, meeting, or assessment platform, whether it was the desktop app or the browser, and its version.
Capture mode
How the screen was captured or shared: single window, browser tab, full display, cloud or local recording, or screenshot.
Test date / tester
The ISO date of the test and who ran it — an internal owner or an independent tester.
Expected / result
What was expected to be visible or excluded, and the observed outcome: pass, partial, fail, or not tested.
Evidence
Where the supporting screenshot, video, or log is retained (an internal evidence reference).
Limitation
Settings, permissions, or unsupported modes that constrain or qualify the result.
Template
Illustrative matrix template
| OS / Build | GhOst version | Platform / Version | Capture mode | Test date / Tester | Expected / Result | Evidence | Limitation |
|---|---|---|---|---|---|---|---|
| Windows or macOS + build | vX.Y.Z | Platform name (desktop or web) + version | window / tab / full display / recording / screenshot | YYYY-MM-DD / internal or independent tester | Expected behavior -> Not tested | Internal evidence reference | Settings, permissions, unsupported modes |
The row above is an illustrative template that shows how a record is structured. Every value is a placeholder, the result is fixed to Not tested, and it must not be read as evidence that any platform passes. No real test results are published on this page.
Evidence
Five-level evidence model
Not all evidence is equal. We rank compatibility evidence from weakest to strongest so any claim can be judged on its footing.
- 1
Unverified marketing claim
A statement with no dated test or retained evidence behind it.
- 2
Vendor demonstration
A one-off demo controlled by the vendor; not independently repeatable.
- 3
Repeatable internal test
A documented test the vendor can reproduce, with recorded environment and retained evidence.
- 4
Independent reproduction
The same result reproduced by a party outside the vendor.
- 5
Continuous compatibility monitoring
Ongoing, dated verification across environments as software changes over time.
This public page currently operates at the transparency level: it publishes the methodology, field definitions, and evidence model above. It does not publish platform-by-platform pass results, and it does not operate a Level 5 continuous public matrix. Treat everything here as transparency about how testing is done — not as a claim that any platform passes.
How to test
Test your own setup safely
- 1
Use a private mock meeting, room, or recording that you own and control — for example, start a meeting with only yourself. Never use a real interview, exam, or another person's session.
- 2
Reproduce the exact capture modes you care about one at a time: single window, browser tab, full display, recording, and screenshot.
- 3
Record your environment precisely: operating system and build, GhOst version, platform and version, and the capture mode used.
- 4
Compare what you expected to be visible or excluded against what actually appears in your own capture.
- 5
Document the date, tester, expected behavior, result, the location of your evidence, and any limitations, using the fields defined above.
- 6
Re-test after any operating system, platform, browser, or GhOst update, because results can change without notice.
These steps are only for evaluating your own setup in environments you control. They are not instructions for defeating monitoring, proctoring, recording, or any other security control, and this page intentionally does not provide such instructions.
Freshness
Change and expiry policy
Any status or expectation described here reflects a point-in-time review and can become outdated without notice.
Compatibility and privacy behavior can change with any operating system, platform, browser, or GhOst update.
This page is reviewed periodically; the Last reviewed date reflects the most recent editorial and product review.
Treat any compatibility statement that is undated, unreferenced, or older than its most recent review as expired until it is re-confirmed with fresh evidence.
Risk
Residual risks
Platform and operating-system updates can change capture and sharing behavior at any time.
Different capture modes — window, full display, recording, and screenshot — can behave differently from one another.
Endpoint or device monitoring, managed devices, and lockdown environments may observe software or behavior outside any single application's control.
Human observation by an interviewer, proctor, or camera is independent of on-screen interface behavior.
Process information, network activity, and account or billing data may be observable in some environments.
Candidate behavior during a session can create signals that no software controls.
Ethics
Responsible use
Use GhOst only where AI assistance is permitted.
Follow the rules of each interview, employer, exam, and platform.
Do not use GhOst to gain an unauthorized advantage, to misrepresent your abilities, or to violate the terms of any assessment.
Preparation and practice in mock settings that you control is the intended use.
The Terms and Privacy pages set out the binding policies.
Contact
Questions or corrections
If you believe a compatibility statement on this site is inaccurate or out of date, or if you have a question about how a claim was tested, please tell us so it can be reviewed.
More
Explore related pages
FAQ
Frequently asked questions
Does GhOst guarantee it will be invisible or undetectable on every platform?
No. GhOst does not claim any universal or guaranteed result. Compatibility and privacy behavior depend on your operating system and build, the platform and its version, the capture mode, your GhOst version, and your settings. No software can promise a specific outcome in every environment.
Is there a live, continuously verified compatibility matrix I can rely on?
Not yet. A continuously verified, public compatibility matrix is not currently available. This page documents the fields, evidence model, and testing methodology used to reason about compatibility, rather than publishing platform-by-platform pass results.
What does GhOst officially document today?
That GhOst is a managed-AI desktop application for Windows and macOS, designed for coding, behavioral, and system-design interviews. That scope describes intended use; it is not a claim that GhOst passes any specific platform, recording, or proctoring check.
How should I read a compatibility claim from any interview tool?
Look for a dated record that lists the operating system and build, the tool version, the platform and version, the capture mode, the tester, the expected behavior, the result, the evidence, and known limitations. Prefer independent reproduction and continuous monitoring over marketing claims or one-off demos, and treat undated or unreferenced claims as unverified.
How can I test compatibility safely myself?
Use a private mock meeting or recording that you own and control, reproduce the exact capture modes you care about, and compare expected against actual results while recording your environment details. Never test against a real interview, a proctored exam, or any session you are not authorized to use, and re-test after updates.
What are the main residual risks?
Platform and operating-system updates, differences between capture modes, endpoint or device monitoring, human observation, and observable process, network, or account information. Candidate behavior during a session can also create signals that no software controls.
Is using GhOst allowed?
Use GhOst only where AI assistance is permitted, and follow the rules of each interview, employer, exam, and platform. It is intended for preparation and for authorized live assistance, not for gaining an unauthorized advantage. See the Terms and Privacy pages for the binding policies.