Fixing Cache Poisoning & Daily-JS Call Issues in the Portal — September 2, 2026

Today, I set out with the goal of fixing two significant issues that had been plaguing my agentic web portal: cache poisoning related to the gp_theme cookie and problems with the daily-js call machine. These challenges were critical because they impacted user experience and the overall functionality of the portal, which is central to my vision for a seamless AI-driven interaction space. I managed to ship two fixes in about an hour, which felt like a small victory in the grand scheme of building this platform.

The first fix addressed a serious issue with the gp_theme cookie. Essentially, the shared nginx page caches were not varying based on the gp_theme, leading to a situation where an anonymous visitor could unintentionally bake a dark-variant page that would then be served to everyone else. This was a classic case of cache poisoning, and it took some digging to identify the root cause. I implemented a guard to ensure that the gp_theme cookie is never server-side rendered for anonymous requests. This change is crucial because it prevents the unintended sharing of theme variations among users who should be seeing the default theme instead.

Next, I tackled the daily-js call issue. The enforced Content Security Policy (CSP) was blocking the eval() function used by the default loader for the daily-js call machine, which caused every Tavus portal call to fail at the join stage. This was another frustrating bug that disrupted the user experience, especially since the daily-js integration is essential for dynamic content delivery. By loading the daily-js call machine without eval, I was able to circumvent this issue. The fix involved setting dailyConfig.avoidEval to true, allowing the machine to load without hitting the CSP restrictions. Implementing this fix required a focused effort to understand the implications of CSP on script loading, but I'm glad to say it worked out in the end.

Reflecting on these fixes, I appreciate the importance of thorough testing and diagnostics when working on a solo project like this. The challenges I faced today reminded me that even small bugs can have significant impacts, especially when building something as intricate as an agentic web portal. Time spent understanding the underlying mechanics of both the theme and the call machine was crucial to resolving these issues effectively.

Working solo with my AI assistant, Claude Code, in VS Code, has its ups and downs. While I have the freedom to experiment and iterate quickly, I also have to be diligent about diagnosing issues independently. The time I spent today was relatively short, but the focus required to solve these two problems felt intense. I often find myself in a rhythm where I can dive deep into a problem, but it can also be exhausting when I hit roadblocks. However, each fix brings me one step closer to my goal of building a one-man-show company with a billion-dollar valuation.

As I look ahead, I am aware that there are more challenges on the horizon. The fixes I implemented today were essential, but they are just part of a larger puzzle. I need to keep pushing forward, refining the portal, enhancing the user experience, and ensuring that the underlying architecture is robust enough to support future features. The journey is long, and while I am proud of the progress I made today, I know there’s still a lot of work ahead.

In summary, today was about tackling two critical bugs that could have derailed user experience on my platform. The fixes for the gp_theme cache poisoning and the daily-js call issues were necessary to maintain the integrity of the agentic web portal. I feel a sense of accomplishment in overcoming these challenges, and I am eager to see how these improvements contribute to the overall vision for hashtag.org. The grind continues, and with each fix, I am one step closer to realizing the potential of this ambitious project.