Fixing Cookie Caching and Portal Call Issues in Spatial AI — September 2, 2026

Today, I focused on resolving two significant issues that were impacting the functionality of my spatial AI platform. The first fix was related to the gp_theme cookie and its handling for anonymous requests, while the second fix addressed a critical issue with the portal call loading process. Both of these problems had the potential to disrupt user experience, and tackling them was essential for maintaining the integrity of the platform.

The first fix I implemented was a guard against cache poisoning regarding the gp_theme cookie. I discovered that the shared nginx page caches were not varying based on the gp_theme, resulting in a scenario where an anonymous user could inadvertently bake a dark-variant page that would be served to all users. This was problematic as it could lead to inconsistencies in user experience and potentially confuse visitors who expected a certain theme. With this fix, I ensured that the gp_theme cookie would not be SSR (Server-Side Rendered) for anonymous requests, effectively preventing any dark-variant page from being cached and served to everyone.

This fix took about 30 minutes of focused effort. I went through the nginx configuration and tested various scenarios to ensure that the cookie behavior was as expected. I also ran some tests to confirm that the changes didn’t introduce new issues. It’s always a bit nerve-wracking to dive into caching configurations, but I felt a sense of accomplishment once I validated that the fix worked as intended. This is a prime example of how one small oversight can lead to a broader problem, and it served as a reminder to always be vigilant with caching strategies.

The second issue I tackled was related to the loading of the daily-js call machine. The enforcement of the Content Security Policy (CSP) was causing the default loader for daily-js to fail due to its reliance on eval(). In this case, the CSP allowed wasm-unsafe-eval but not unsafe-eval, which meant that every Tavus portal call was failing to join properly. This was a critical issue since it affected the functionality of the portal and the user experience.

I spent another focused 30 minutes resolving this issue. The fix involved modifying the loading process to avoid using eval() altogether. Instead, I adjusted the configuration to use dailyConfig.avoidEval, which allowed the call machine to load without triggering the CSP restrictions. After implementing the change, I ran multiple tests to ensure that the portal calls were functioning correctly. I was relieved to see that everything operated smoothly afterward. This fix was a testament to the importance of understanding the CSP and how it interacts with different parts of the application.

Reflecting on today’s work, it’s clear that even in a solo development environment, small issues can snowball into significant user experience problems if not addressed promptly. These fixes, while not glamorous, were crucial for maintaining the integrity of the spatial AI platform. Working with Claude Code in VS Code allowed me to iterate quickly and efficiently, which is vital when you’re building something as ambitious as the agentic web.

Being a one-man show is challenging, especially when dealing with bugs that can eat up your time. However, each fix I implement brings me one step closer to my goal of creating a billion-dollar valuation company. The learning curve is steep, but so is the satisfaction of solving these problems independently. It’s a grind, but I’m proud of the progress I made today. As I move forward, I’ll continue to keep an eye on caching and CSP-related issues, ensuring that my platform remains robust and user-friendly. Today was a reminder that the devil is in the details, and I intend to keep those details in check as I build out more features in the future.